strace analysis shows that the issue is caused by a single SQL query:
SELECT routerports.router_id AS routerports_router_id, routerports.port_id AS routerports_port_id, routerports.port_type AS routerports_port_type, ipallocations_1.port_id AS ipallo
cations_1_port_id, ipallocations_1.ip_address AS ipallocations_1_ip_address, ipallocations_1.subnet_id AS ipallocations_1_subnet_id, ipallocations_1.network_id AS ipallocations_1_network_id, ports_1.tenant
_id AS por....
which has list of parameters with ~1000 items
the response size is about 2G, after reading the response process starts to call mmap() retrieving more memory.
overall the processing takes several minutes.
Neutron function that matches query pattern is l3_db.get_sync_interfaces()
strace analysis shows that the issue is caused by a single SQL query:
SELECT routerports. router_ id AS routerports_ router_ id, routerports.port_id AS routerports_ port_id, routerports. port_type AS routerports_ port_type, ipallocations_ 1.port_ id AS ipallo 1.ip_address AS ipallocations_ 1_ip_address, ipallocations_ 1.subnet_ id AS ipallocations_ 1_subnet_ id, ipallocations_ 1.network_ id AS ipallocations_ 1_network_ id, ports_1.tenant
cations_1_port_id, ipallocations_
_id AS por....
which has list of parameters with ~1000 items
the response size is about 2G, after reading the response process starts to call mmap() retrieving more memory.
overall the processing takes several minutes.
Neutron function that matches query pattern is l3_db.get_ sync_interfaces ()