Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1131976
| 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 |
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
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