Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1131976

Bug#1027337: "Starting cleanup"

From Xan Charbonnet <xan@charbonnet.com>
Newsgroups linux.debian.bugs.dist
Subject Bug#1027337: "Starting cleanup"
Date 2023-01-06 15:30 +0100
Message-ID <FKVTj-g0hF-7@gated-at.bofh.it> (permalink)
References <FIqgV-emzB-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Every few seconds (at least in my configuration), PDNS runs database 
queries to see which domains need refreshing.

After running for a while with this problem, I can "catch" those queries 
(at least one of them) with SHOW PROCESSLIST.
Excerpt:
| 117 | pdns | localhost | pdns | Execute |    0 | Starting cleanup | 
SELECT content,ttl,prio,type,domain_id,disabled,name,auth FROM records 
WHERE disabled=0 and type=? and name=? |    0.000 |

It seems to me that the longer this problem has been going on, the 
longer this query takes, at least the "starting cleanup" phase of it.  I 
think that's why CPU usage climbs: the longer it goes, the longer this 
query takes and the more CPU is used to execute it.

Caught a different one just now, also in phase "starting cleanup":
| 128 | pdns | localhost | pdns | Execute |    0 | Starting cleanup | 
SELECT content,ttl,prio,type,domain_id,disabled,name,auth FROM records 
WHERE disabled=0 and name=? and domain_id=? |    0.000 |

Yes, I can regularly "catch" many queries and they're always in state 
"starting cleanup".

I went over to the machine that is not having this problem (because it's 
still on 10.5.15) and was able to catch one such query in "starting 
cleanup", and another in "commit".  But it took maybe 25x more attempts 
to catch such a query than on the one with the problem.  The queries on 
the "good" box finish very quickly, and they're slow on the "bad" box.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18 Xan Charbonnet <xan@charbonnet.com> - 2022-12-30 17:20 +0100
  Bug#1027337: Update Xan Charbonnet <xan@charbonnet.com> - 2022-12-31 23:10 +0100
  Bug#1027337: Update 2 Xan Charbonnet <xan@charbonnet.com> - 2023-01-02 20:10 +0100
  Bug#1027337: second that bug Andreas Laut <andreas.laut@spark5.de> - 2023-01-05 15:20 +0100
    Bug#1027337: second that bug Julien Banchet <jbanchet@cusae.com> - 2023-01-05 16:20 +0100
      Bug#1027337: second that bug Andreas Laut <andreas.laut@spark5.de> - 2023-01-06 09:10 +0100
  Bug#1027337: "Starting cleanup" Xan Charbonnet <xan@charbonnet.com> - 2023-01-06 15:30 +0100
  Bug#1027337: [debian-mysql] Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18 Faustin Lammler <faustin@fala.red> - 2023-01-10 13:40 +0100
  Bug#1027337: [debian-mysql] Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18 Xan Charbonnet <xan@charbonnet.com> - 2023-01-10 17:10 +0100
    Bug#1027337: [debian-mysql] Bug#1027337: Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18 Faustin Lammler <faustin@fala.red> - 2023-01-10 20:00 +0100
  Bug#1027337: [debian-mysql] Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18 fmaesen <fmaesen@gmail.com> - 2023-02-07 16:40 +0100
  Bug#1027337: [debian-mysql] Bug#1027337: Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18 Faustin Lammler <faustin@fala.red> - 2023-02-28 18:30 +0100
    Bug#1027337: [debian-mysql] Bug#1027337: Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18 Otto Kekäläinen <otto@debian.org> - 2023-03-01 07:40 +0100

csiph-web