mysqld continue op 100%

[X-DraGoN]

Ik heb hier een 'oude' server geërfd met Ubuntu 14.04 (die mag niet geupgrade worden door allerlei externe redenen).
Daar draaien verschillende services op, waaronder een Tomcat 7.5 based applicatie en een mysqld (mysqld 5.5.62-0ubuntu0.14.04.1)
Nu, die mysqld gebruikt 1 CPU volledig van dat machine, zowat constant.
Ik ben op onderzoek gegaan en door middel van een strace zag ik dit:

code:

open("/[b]etc/hosts.deny[/b]", O_RDONLY)       = 32
fstat(32, {st_mode=S_IFREG|0644, st_size=711, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6360633000
read(32, "# /etc/hosts.deny: list of hosts"..., 4096) = 711
read(32, "", 4096)                      = 0
close(32)                               = 0
munmap(0x7f6360633000, 4096)            = 0
getsockname(31, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
fcntl(31, F_SETFL, O_RDONLY)            = 0
fcntl(31, F_GETFL)                      = 0x2 (flags O_RDWR)
setsockopt(31, SOL_SOCKET, SO_RCVTIMEO, "\36\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
setsockopt(31, SOL_SOCKET, SO_SNDTIMEO, "<\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
fcntl(31, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
setsockopt(31, SOL_IP, IP_TOS, [8], 4)  = 0
setsockopt(31, SOL_TCP, TCP_NODELAY, [1], 4) = 0
futex(0x5574ccacad84, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x5574ccacad80, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x5574ccac87e0, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=10, events=POLLIN}, {fd=12, events=POLLIN}], 2, 4294967295) = 1 ([{fd=10, revents=POLLIN}])
fcntl(10, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
accept(10, {sa_family=AF_INET, sin_port=htons(36782), sin_addr=inet_addr("127.0.0.1")}, [16]) = 31
fcntl(10, F_SETFL, O_RDWR)              = 0
rt_sigaction(SIGCHLD, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x7f635edfbcb0}, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x7f635edfbcb0}, 8) = 0
getpeername(31, {sa_family=AF_INET, sin_port=htons(36782), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
getsockname(31, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
open("[b]/etc/hosts.allow[/b]", O_RDONLY)      = 32
fstat(32, {st_mode=S_IFREG|0644, st_size=411, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6360633000
read(32, "# /etc/hosts.allow: list of host"..., 4096) = 411
read(32, "", 4096)                      = 0
close(32)                               = 0
munmap(0x7f6360633000, 4096)            = 0
open("/etc/hosts.deny", O_RDONLY)       = 32
fstat(32, {st_mode=S_IFREG|0644, st_size=711, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6360633000
read(32, "# /etc/hosts.deny: list of hosts"..., 4096) = 711
read(32, "", 4096)                      = 0
close(32)                               = 0
munmap(0x7f6360633000, 4096)            = 0
getsockname(31, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
fcntl(31, F_SETFL, O_RDONLY)            = 0
fcntl(31, F_GETFL)                      = 0x2 (flags O_RDWR)
setsockopt(31, SOL_SOCKET, SO_RCVTIMEO, "\36\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
setsockopt(31, SOL_SOCKET, SO_SNDTIMEO, "<\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
fcntl(31, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
setsockopt(31, SOL_IP, IP_TOS, [8], 4)  = 0
setsockopt(31, SOL_TCP, TCP_NODELAY, [1], 4) = 0
futex(0x5574ccacad84, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x5574ccacad80, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
poll([{fd=10, events=POLLIN}, {fd=12, events=POLLIN}], 2, 4294967295^CProcess 1215 detached
 <detached ...>

Met andere woorden heel veel hits op /etc/hosts.allow en /etc/hosts.deny
Beide files hebben geen inhoud buiten de standaard headers

code:

~$ cat /etc/hosts.allow
# /etc/hosts.allow: list of hosts that are allowed to access the system.
#                   See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: LOCAL @some_netgroup
#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.

In de volgende link had ik gevonden dat dat eventueel met DNS te maken kon hebben:
Er stonden eerst instellingen inderdaad verkeerd, van lang geleden, maar deze zijn allemaal rechtgezet (resolv.conf geeft nu de juiste DNS servers aan.
my.cnf is ook aangepast met "skip-name-resolve" (en herstart)
maar uiteindelijk, na al deze aanpassingen blijft mysqld naar 100% schieten zonder verklaarbare reden.
Het échte werk waarvoor er een mysqld opstaat, op die server, moet dagelijks gebeuren en gebeurd ook, maar uiteraard trager als het zou kunnen.

Heeft er iemand een idee hoe dit zou kunnen komen of wat ik nog verder kan doen om te achterhalen waarom mysqld die tcpwrappers gebruikt? of vanwaar die instructies komen om die reads te doen?

[Bart]

Hangt die MySQL service toevallig publiek, zonder IP whitelisting, aan het internet (of via NAT/port forwarding)? If so, dan worden er misschien wel massaal inlogpogingen gedaan waardoor die veel resources opslokt.

[X-DraGoN]

Die server hangt via NAT inderdaad op internet, maar die 3306 port staat niet exposed naar buiten toe
In de my.cnf config file staat bind-address op 127.0.0.1 en op de firewall staat die poort helemaal niet open.

[ripperke]

hosts.deny/allow zal wel bij elke connectie gecontroleerd worden.

Zet even de general log aan (e.g. https://stackoverflow.com/a/72531262/5414711) en check vanwaar de connecties komen.

show processlist; in de mysql console kan soms ook verhelderend zijn.

[RBakkum]

Je zou eens kunnen kijken naar:
https://dev.mysql.com/doc...#sysvar_skip_name_resolve

In andere woorden, het kan zijn dat er dus een resolving plaats vind bij elke connectie. Wat je dus uit kan zetten en je dus alleen op 'ip basis' je host kan opgeven.

Je zou voor je zoiets aanzet eerst even in je user / host list moeten kijken of je niet dingen stuk maakt:
SELECT user,host FROM mysql.user;

EDIT:
Volgens mij gaat de setting niet actief worden als er 1 user / host actief is die name based is, en dus is het voor alles nog actief zolang die dus bestaat

[ Voor 15% gewijzigd door RBakkum op 13-06-2024 17:17 ]

[fopjurist]

Leuk gevonden van hosts.allow en hosts.deny, en je kunt er kennelijk een hoop mensen het bos mee insturen, maar het lezen van een bijna leeg tekstbestand zorgt niet voor 100% cpu. Draai poor man's profiler maar eens (nsamples iets hoger zetten) en houd de processlist (pagina 1563 in de handleiding) in de gaten.

[Hero of Time]

Eerste punt eerst. MySQL is een stuk server software en hoort derhalve in Server Software en Clouddiensten. LNX -> SSC.

Tweede punt:
Deze machine moet je compleet van het internet af halen, niks, maar dan ook niks mag meer naar die machine gaan. Het is lek, oud, had al meer dan 5 jaar geleden vervangen moeten zijn. Wat er op draait moet verhuist worden, geen discussie mogelijk. Service die erop draait alleen intern benaderbaar hebben en zo strak mogelijk beperken.

Derde punt:
Ga uitzoeken wat MySQL nou werkelijk doet. Als er 1 core 100% wordt belast, is dat hoogstwaarschijnlijk een query die ontiegelijk ruk is geschreven en veel te veel doet dan nodig is. Die tomcat instance dat erop staat zal vast verbinding maken met de database, stop die en kijk wat er dan gebeurt. Is het gebruik weg, dan is er iets dat via Tomcat de boel aan het zieken is. Blijft het, kijk dan intern naar processlist zoals eerder aangegeven.

Niet blind staren op een strace en zeker niet naar bestanden die het regelmatig opent.

[jnr24]

process list bekijken en slow queries loggen (of ze in de general log zetten, afhankelijk hoe druk dat systeem is tijdens dagelijks werk)

[fopjurist]

Hero of Time schreef op donderdag 13 juni 2024 @ 19:59:

Deze machine moet je compleet van het internet af halen, niks, maar dan ook niks mag meer naar die machine gaan. Het is lek, oud, had al meer dan 5 jaar geleden vervangen moeten zijn. Wat er op draait moet verhuist worden, geen discussie mogelijk. Service die erop draait alleen intern benaderbaar hebben en zo strak mogelijk beperken.

Ubuntu 14.04 krijgt nog steeds beveiligingsupdates.

[Aganim]

fopjurist schreef op donderdag 13 juni 2024 @ 20:33:
[...]

Ubuntu 14.04 krijgt nog steeds beveiligingsupdates.

Bij mijn weten alleen als je Pro Support afneemt, de reguliere ondersteuning was 5 jaar geleden al klaar.

[Hero of Time]

fopjurist schreef op donderdag 13 juni 2024 @ 20:33:
[...]

Ubuntu 14.04 krijgt nog steeds beveiligingsupdates.

Nee, dat krijgt het niet. 5 jaar door Canonical, dat was tot 2019, en 5 jaar door een derde partij, dat is nu 1,5 maand voorbij. En dan nog wil je geen OS van 10 jaar oud met discutabele staat blijven draaien. Het zou mij ook niet verbazen als er sinds installatie geen enkele update is toegepast, want leverancier zal wel hebben gezegd "dit is hoe het werkt" en de klant blijft er verders van af omdat ze niet de kennis in huis hebben. Anders had er al wel wat nieuwer gedraaid.

[jnr24]

Partijen die dergelijke Pro/LTSS support contracten hebben afgesloten stoppen zo'n doos meestal niet in de erfenis daar blijven meestal wel een paar familieleden op passen.

Ik denk ook dat die in geen tien jaar meer updates hebben gezien.

Heb je binlogs? Die kan je naar je laptop of zo kopieren en dan eens bekijken en zelfs afspelen op een backup/kopie database (ik hoop dat die er wel is anders is dit een uitgelezen moment)

Heb je functioneel een idee wat er gebeurd? 10 of 10000 sessies per dag. Is het een systeem met 1GB of 100GB aan data?

Backup/housekeeping kan de boel ook verstieren, tabellen worden te groot en te traag omdat in een uurtje af te handelen en daarna krijg je een mooie wachtrij met dagelijkse backups.

[ Voor 9% gewijzigd door jnr24 op 14-06-2024 02:11 ]

[SVMartin]

En is het een virtuele of fysieke machine?

[CrankyGamerOG]

Hero of Time schreef op donderdag 13 juni 2024 @ 20:44:
[...]

Het zou mij ook niet verbazen als er sinds installatie geen enkele update is toegepast, want leverancier zal wel hebben gezegd "dit is hoe het werkt".

100%, ik moet in mijn organisatie constant lopen zeulen en zeuren en trekken om shit up to date te houden.
nachtmerrie.

[_JGC_]

mysql connectie maken, dan de volgende commando's:

set global log_queries_not_using_indexes=on;
set global slow_query_log=on;

5 minuten laten lopen en dan weer op off zetten.

En dan in /var/lib/mysql kijken naar een [hostname]-slow.log bestandje. 100% CPU bij MySQL is vrijwel altijd een aantal queries die bij het ontwerpen van de applicatie snel waren, maar na 10 jaar data toevoegen aan de tabellen zorgt voor full table scans omdat er geen enkele index op de tabellen is gezet.

Bestand bevat dan regels als dit:
Query_time: 6.898409 Lock_time: 0.000096 Rows_sent: 1 Rows_examined: 34041
Met daaronder de query. Kijken naar de query, juiste index zetten en dan is MySQL ineens wel snel.

[pennywiser]

Aganim schreef op donderdag 13 juni 2024 @ 20:44:
[...]

Bij mijn weten alleen als je Pro Support afneemt, de reguliere ondersteuning was 5 jaar geleden al klaar.

Pro bestaat nog niet zo lang 14.04 - kreeg de volledige 10 jaar updates.

ECHTER, sinds begin dit jaar is het zo als je Pro wel toepast op 14.04 krijg je zelfs 12 jaar updates.

https://canonical.com/blo...ing-with-ubuntu-14-04-lts

[pennywiser]

Hero of Time schreef op donderdag 13 juni 2024 @ 20:44:
[...]

Nee, dat krijgt het niet. 5 jaar door Canonical, dat was tot 2019, en 5 jaar door een derde partij, dat is nu 1,5 maand voorbij. En dan nog wil je geen OS van 10 jaar oud met discutabele staat blijven draaien. Het zou mij ook niet verbazen als er sinds installatie geen enkele update is toegepast, want leverancier zal wel hebben gezegd "dit is hoe het werkt" en de klant blijft er verders van af omdat ze niet de kennis in huis hebben. Anders had er al wel wat nieuwer gedraaid.

Door Canonical dus.

[pennywiser]

@X-DraGoN Kan je je slow queries eens uitlezen? Wat @_JGC_ ook zegt en zijn post is clever thinking overigens.

https://www.prisma.io/dat.../identifying-slow-queries

Die hosts.deny kan je gewoon eens disablen, dan weet je of het daaraan ligt.

[ Voor 33% gewijzigd door pennywiser op 15-06-2024 16:59 ]