Uploaded image for project: 'OpenShift Core Networking'
  1. OpenShift Core Networking
  2. CORENET-4270

[Scale] Optimize the memory footprint of ovnkube-node pod with IC {PostFeatureFreeze: Approved}

    • Icon: Story Story
    • Resolution: Done
    • Icon: Major Major
    • None
    • None
    • None
    • Strategic Product Work
    • False
    • None
    • False
    • OCPSTRAT-379 - OVN Interconnect work: Part2
    • ---
    • SDN Sprint 238, SDN Sprint 239, SDN Sprint 240, SDN Sprint 241
    • 0

      Work with https://issues.redhat.com/browse/SDN-3654 card to get data from scale team as needed and continue to improvise the numbers.

            [CORENET-4270] [Scale] Optimize the memory footprint of ovnkube-node pod with IC {PostFeatureFreeze: Approved}

            https://github.com/openshift/cluster-network-operator/pull/1971 is done, this is as far as we go in 4.14 for optimizing MEM, closing this card.

            Improvement presentations were done at scale meetings for MEM.

            Surya Seetharaman added a comment - https://github.com/openshift/cluster-network-operator/pull/1971 is done, this is as far as we go in 4.14 for optimizing MEM, closing this card. Improvement presentations were done at scale meetings for MEM.

            Surya Seetharaman added a comment - https://github.com/ovn-org/ovn-kubernetes/pull/3807

            includes

            syncNodesPeriodic: get nodes from cache

             

            Nadia Pinaeva added a comment - includes syncNodesPeriodic: get nodes from cache  

            includes

            Netpol retryFramework cleanup

            Nadia Pinaeva added a comment - includes Netpol retryFramework cleanup

            includes

            service controller: use shared InformerFactory

            Nadia Pinaeva added a comment - includes service controller: use shared InformerFactory

            we are waiting on vkommadi@redhat.com to be back and give us the heap profile to proceed here, as of now npinaeva@redhat.com has not seen any major MEM regressions that were reported in previous scale meeting.

            moving card to progress because we are working on enhancing MEM bit by bit.

            Surya Seetharaman added a comment - we are waiting on vkommadi@redhat.com to be back and give us the heap profile to proceed here, as of now npinaeva@redhat.com has not seen any major MEM regressions that were reported in previous scale meeting. moving card to progress because we are working on enhancing MEM bit by bit.

            npinaeva@redhat.com : You mentioned you are working on all of the bugs - both MEM and CPU? Does that mean this card should be assigned to you as well?

            Surya Seetharaman added a comment - npinaeva@redhat.com : You mentioned you are working on all of the bugs - both MEM and CPU? Does that mean this card should be assigned to you as well?

            Un-assigning this card since Zenghui does not have the cycles right now.

            Surya Seetharaman added a comment - Un-assigning this card since Zenghui does not have the cycles right now.

            How can we reduce the CPU usage on each worker 

            Surya Seetharaman added a comment - How can we reduce the CPU usage on each worker 

            zshi@redhat.com : would you be willing to take this card? its almost in line with what you do for microshift though this isn't specific to microshift deployments, more so for the default OCP use case as well.

            Surya Seetharaman added a comment - zshi@redhat.com : would you be willing to take this card? its almost in line with what you do for microshift though this isn't specific to microshift deployments, more so for the default OCP use case as well.

              npinaeva@redhat.com Nadia Pinaeva
              sseethar Surya Seetharaman
              Tim Rozet
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: