Bonjour
J'ai un problème qui revient.
Des sites qui se bloquent en timeout.
Mais un truc à la fois !
**Je fais une commande REBOOT… **
Elle ne se fait pas (ou parfois très longtemps après !
Il reste de TRÈS nombreuses tâches MariaDB !
Je les vois avec HTOP.
Je suppose, en wait, et elle bloquent le reboot ?
ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 165880 8692 ? Ss Aug18 11:58 /sbin/init
root 57 0.0 0.6 64252 28152 ? Ss Aug18 0:02 /lib/systemd/systemd-journald
message+ 118 0.0 0.1 8784 4148 ? Ss Aug18 0:10 @dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslo
root 121 0.0 0.8 129980 35560 ? Ssl Aug18 0:00 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid
systemd+ 154 0.0 0.1 16136 5456 ? Ss Aug18 0:00 /lib/systemd/systemd-networkd
systemd+ 165 0.0 0.2 25280 9704 ? Ss Aug18 0:00 /lib/systemd/systemd-resolved
root 211 0.0 0.1 234900 6768 ? Ssl Aug18 0:00 /usr/libexec/polkitd --no-debug
mysql 295 0.0 12.2 2373900 509628 ? Ssl Aug18 2:21 /usr/sbin/mariadbd
root 223935 0.0 0.0 8168 3672 pts/3 Ss 10:45 0:00 /bin/bash
root 236425 0.0 0.0 10740 3528 pts/3 R+ 12:17 0:00 ps -aux
HTOP :
0[| 0.7%] Tasks: 10, 51 thr; 1 running
1[|| 2.7%] Load average: 1.40 2.34 2.67
2[|| 2.0%] Uptime: 1 day, 12:37:01
Mem[|||||||||||||||||||||||||||||||||||| 634M/3.95G]
Swp[ 0K/512M]
PID USER PRI NI VIRT RES SHR S CPU%▽MEM% TIME+ Command
295 mysql 20 0 2318M 497M 11296 S 1.3 12.3 2:22.58 /usr/sbin/mariadbd
1 root 20 0 161M 8692 5528 S 0.0 0.2 11:58.78 /sbin/init
57 root 20 0 64252 28156 27000 S 0.0 0.7 0:02.80 /lib/systemd/systemd-journald
118 messagebu 20 0 8784 4148 3292 S 0.0 0.1 0:10.25 @dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-
121 root 20 0 126M 35560 12252 S 0.0 0.9 0:00.82 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid
154 systemd-n 20 0 16136 5456 4468 S 0.0 0.1 0:00.65 /lib/systemd/systemd-networkd
165 systemd-r 20 0 25280 9704 5680 S 0.0 0.2 0:00.29 /lib/systemd/systemd-resolved
211 root 20 0 229M 6768 5480 S 0.0 0.2 0:00.10 /usr/libexec/polkitd --no-debug
214 root 20 0 229M 6768 5480 S 0.0 0.2 0:00.00 /usr/libexec/polkitd --no-debug
216 root 20 0 229M 6768 5480 S 0.0 0.2 0:00.05 /usr/libexec/polkitd --no-debug
238 root 20 0 126M 35560 12252 S 0.0 0.9 0:00.00 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid
302 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:16.80 /usr/sbin/mariadbd
426 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.13 /usr/sbin/mariadbd
428 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.33 /usr/sbin/mariadbd
436 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
437 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
150077 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:05.51 /usr/sbin/mariadbd
151636 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:03.81 /usr/sbin/mariadbd
162801 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.13 /usr/sbin/mariadbd
179340 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.03 /usr/sbin/mariadbd
182446 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.14 /usr/sbin/mariadbd
183964 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.02 /usr/sbin/mariadbd
186952 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.23 /usr/sbin/mariadbd
192159 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.01 /usr/sbin/mariadbd
193151 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
194157 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
194765 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
194767 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
194782 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.80 /usr/sbin/mariadbd
196967 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
197017 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
197482 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
197584 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
197586 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
197615 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
198111 mysql 20 0 2318M 497M 11296 S 0.0 12.3 0:00.00 /usr/sbin/mariadbd
etc …
Une idée de ce qui bloque ces MariaDB ?
Et pourquoi le reboot ne les force pas down ?
J'arrive à forcer le reboot avec
kill -9 295 (le PID de MariaDB)
bon, ce n'est pas top !
Bon WE
Il faut vérifier le disque, les erreurs entrée sortie ou voir s'il s'apprête à tomber en panne.
je peux vérifier le disque.
Mais ce sont 2 SSD en RAID, avec Proxmox.
C'est un conteneur, et je n'ai ce problème qu'avec ce conteneur …
Les autres tournent normalement.
Ce conteneur Proxmox est mon 1er avec Ubuntu 22.04 et MariaDB.
Mais ok, je vais vérifier le statut RAID dans le serveur Proxmox.
Bon WE
le statut RAID soft
# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 nvme1n1p2[1] nvme0n1p2[0]
1047552 blocks super 1.2 [2/2] [UU]
md5 : active raid1 nvme1n1p5[0] nvme0n1p5[1]
476381184 blocks super 1.2 [2/2] [UU]
bitmap: 4/4 pages [16KB], 65536KB chunk
md3 : active raid1 nvme1n1p3[1] nvme0n1p3[0]
20955136 blocks super 1.2 [2/2] [UU]
======================================
J'ai testé tous mes volumes RAID, et tout semble bon :
# mdadm --detail /dev/md5
/dev/md5:
Version : 1.2
Creation Time : Sat Feb 19 07:13:30 2022
Raid Level : raid1
Array Size : 476381184 (454.31 GiB 487.81 GB)
Used Dev Size : 476381184 (454.31 GiB 487.81 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sat Aug 20 16:09:21 2022
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : md5
UUID : e166afb1:1595c386:77ab68fa:8824fc5a
Events : 3422
Number Major Minor RaidDevice State
0 259 12 0 active sync /dev/nvme1n1p5
1 259 5 1 active sync /dev/nvme0n1p5
Il faudrait essayer smartctl :
https://www.malekal.com/smartctl-verifier-son-disque-en-ligne-de-commandes-linux/
> smartctl -l selftest /dev/nvme1n1p5
> smartctl -l selftest /dev/nvme0n1p5
Et regarder s'il y a des erreurs indiquées.
Il faut aussi faire un fsck sur les partitions.
Si tout est bon, il faudra chercher côté système aussi, dans la base de données, des indexes corrompus,...
Sur le serveur Proxmox :
sur le 1er disque NVME :
Proxmox:~# smartctl -a /dev/nvme0n1
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.39-2-pve] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: WDC CL SN720 SDAQNTW-512G-2000
Serial Number: 202716800666
Firmware Version: 10109122
PCI Vendor/Subsystem ID: 0x15b7
IEEE OUI Identifier: 0x001b44
Total NVM Capacity: 512,110,190,592 [512 GB]
Unallocated NVM Capacity: 0
Controller ID: 8215
NVMe Version: 1.3
Number of Namespaces: 1
Namespace 1 Size/Capacity: 512,110,190,592 [512 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 001b44 8b496072c4
Local Time is: Sun Aug 21 00:53:20 2022 CEST
Firmware Updates (0x14): 2 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x001f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Log Page Attributes (0x02): Cmd_Eff_Lg
Maximum Data Transfer Size: 128 Pages
Warning Comp. Temp. Threshold: 80 Celsius
Critical Comp. Temp. Threshold: 85 Celsius
Namespace 1 Features (0x02): NA_Fields
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 5.50W - - 0 0 0 0 0 0
1 + 3.50W - - 1 1 1 1 0 0
2 + 3.00W - - 2 2 2 2 0 0
3 - 0.0700W - - 3 3 3 3 4000 10000
4 - 0.0025W - - 4 4 4 4 4000 45000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 2
1 - 4096 0 1
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 41 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 65%
Data Units Read: 120,335,385 [61.6 TB]
Data Units Written: 518,156,721 [265 TB]
Host Read Commands: 1,903,097,081
Host Write Commands: 12,097,725,387
Controller Busy Time: 20,259
Power Cycles: 28
Power On Hours: 14,922
Unsafe Shutdowns: 20
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Error Information (NVMe Log 0x01, 16 of 256 entries)
No Errors Logged
sur le 2ème disque NVME :
Proxmox:~# smartctl -a /dev/nvme1n1
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.39-2-pve] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: WDC CL SN720 SDAQNTW-512G-2000
Serial Number: 1851BC802502
Firmware Version: 10104122
PCI Vendor/Subsystem ID: 0x15b7
IEEE OUI Identifier: 0x001b44
Total NVM Capacity: 512,110,190,592 [512 GB]
Unallocated NVM Capacity: 0
Controller ID: 8215
NVMe Version: 1.3
Number of Namespaces: 1
Namespace 1 Size/Capacity: 512,110,190,592 [512 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 001b44 8b4412e720
Local Time is: Sun Aug 21 00:55:40 2022 CEST
Firmware Updates (0x14): 2 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x001f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Log Page Attributes (0x02): Cmd_Eff_Lg
Maximum Data Transfer Size: 128 Pages
Warning Comp. Temp. Threshold: 80 Celsius
Critical Comp. Temp. Threshold: 85 Celsius
Namespace 1 Features (0x02): NA_Fields
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 5.50W - - 0 0 0 0 0 0
1 + 3.50W - - 1 1 1 1 0 0
2 + 3.00W - - 2 2 2 2 0 0
3 - 0.0700W - - 3 3 3 3 4000 10000
4 - 0.0025W - - 4 4 4 4 4000 45000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 2
1 - 4096 0 1
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 45 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 205,420,378 [105 TB]
Data Units Written: 944,921,483 [483 TB]
Host Read Commands: 2,808,839,435
Host Write Commands: 18,969,308,298
Controller Busy Time: 34,785
Power Cycles: 38
Power On Hours: 29,789
Unsafe Shutdowns: 30
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Error Information (NVMe Log 0x01, 16 of 256 entries)
No Errors Logged
Je ne vois pas d'erreur
Mes sites (Drupal) bloquent de nouveau.
Pas encore essayé le reboot.
Je vois que Apache a bcp de messages d'erreurs :
[Sun Aug 21 04:18:32.971378 2022] [proxy_fcgi:error] [pid 64298:tid 140368473462336] (70007)The timeout specified has expired: [client 88.99.244.56:55164] AH01075: Error dispatching request to : (polling)
[Sun Aug 21 04:18:45.164749 2022] [proxy_fcgi:error] [pid 98185:tid 140368079201856] (70007)The timeout specified has expired: [client 88.99.244.56:56666] AH01075: Error dispatching request to : (polling)
[Sun Aug 21 04:18:57.223460 2022] [proxy_fcgi:error] [pid 98131:tid 140367466829376] (70007)The timeout specified has expired: [client 88.99.244.56:58072] AH01075: Error dispatching request to : (polling)
[Sun Aug 21 04:19:04.744121 2022] [proxy_fcgi:error] [pid 98185:tid 140368070809152] (70007)The timeout specified has expired: [client 66.249.66.194:48582] AH01075: Error dispatching request to : (polling)
[Sun Aug 21 04:19:09.283392 2022] [proxy_fcgi:error] [pid 98131:tid 140368515425856] (70007)The timeout specified has expired: [client 88.99.244.56:59600] AH01075: Error dispatching request to : (polling)
[Sun Aug 21 04:19:21.339872 2022] [proxy_fcgi:error] [pid 98185:tid 140367382967872] (70007)The timeout specified has expired: [client 88.99.244.56:32794] AH01075: Error dispatching request to : (polling)
[Sun Aug 21 04:19:32.807416 2022] [proxy_fcgi:error] [pid 98185:tid 140367357789760] (70007)The timeout specified has expired: [client 192.175.111.233:15387] AH01075: Error dispatching request to : (polling)
[Sun Aug 21 04:19:33.396289 2022] [proxy_fcgi:error] [pid 64298:tid 140368423106112] (70007)The timeout specified has expired: [client 88.99.244.56:34302] AH01075: Error dispatching request to : (polling)
Mais difficile de dire si c'est Apache2, PHP, ou MariaDB, puisque tout à l'heure MariaDB empêchait le reboot…
proxy_fcgi:error
ça semble bien être un problème entre Apache2, le Proxy et PHP…
MariaDB est problème impacté mais pas responsable ?
--------------------
If php-fpm is installed edit/create:
vi /etc/httpd/conf.modules.d/00-proxy_timeout.conf
and add the lines
Timeout 1200
ProxyTimeout 1200
ça me parait énorme un timeout sur 20 minutes !
Mais plusieurs sites donnent des solutions de ce genre.
J'ai ajouté une ligne pour le timeout dans apache2.conf
J'ai fait les stop / start de Apache2 et FPM.
Les sites sont "not found"…
J'essaie : service mariadb stop
et ça bloque!
La commande ne se termine pas !
Exactement comme quand j'avais rebooté
Je refais reboot.
ça me redonne la main, mais le conteneur ne s'arrête pas !
Htop me dit qu'il reste des tâches MariaDB !
Je force le stop de MariaDB avec un kill -9
Immédiatement le conteneur reboot et je retourne au prompt Proxmox.
Le reboot est OK et les 2 sites sont disponibles.
--------------------
ok, j'ai ajouté un ligne pour le timeout du proxy. dans apache2.conf
`RequestReadTimeout handshake=0 header=20-600,MinRate=500 body=20,MinRate=500`
Je verrai si cela empêche le blocage.
Merci et bon dimanche
Les blocages semblent avoir lieu au moment précis aussi quand il tente de synchroniser le cache sur le disque, à la fin du reboot ou des moments comme ça.
Quand le système boot et juste après, il écrit dans le cache donc là, ça semble rapide et puis quand le cache mémoire est assez plein et qu'il doit commencer à écrire plus souvent sur le disque, là ça ralentit.
C'est pour ça que je me dis que les écritures sur le disque sont peut être anormalement lentes/bloquées et qu'il se peut qu'un des disques a un problème.
Je crois qu'il y a d'autres paramètre à smartctl pour tester les disques et avoir des tableaux avec des erreurs à 0 ou plus.
Peut-être aussi un test à faire serait de désactiver un des disque du RAID, voir si ça accélère, remettre le disque dans le RAID, attendre la synchro et faire la même chose avec l'autre disque.
Il peut y avoir un problème similaire aussi si le conteneur pense avoir 8Go de RAM mais que l'hôte lui en fait donné 4Go en RAM et 4Go sur disque(swap) pour économiser (j'ai déjà eu le problème).
Bonjour,
c'est quoi la config du conteneur ?
c'est une stack avec du PHP-FPM ?
Si oui est-ce le "pm.max_children" sature ? (voir phpX.X-fpm.log si comme debian)
PVE à jour ?
LXC à jour ?
Le CT se fait backuper via proxmox (ce serait pas ce bug du coup qui te casse le CT : https://forum.proxmox.com/threads/snapshot-backup-not-working-guest-agent-fs-freeze-gets-timeout.99887) ?
Sur le CT c'est un stack "maison" ou un panel ?
Cordialement, janus57
Bonjour Janus
C'est un simple conteneur Proxmox, avec le template Ubuntu 22.02
RAM 4 GB
swap 512 MB
cpu 3
Disk 10 GB
J'ai ensuite installé Virtualmin / Webmin qui était en béta pour Ubuntu 22.04.
C'est du PHP-FPM oui.
Le conteneur est à jour.
J'ai fait les màj du serveur Proxmox régulièrement : actuellement 7.2.7
Mais c'est une install "OVH", càd avec RAID soft ext4, et pas ZFS comme recommandé.
Lors de ma dernière réinstallation car problème disque (j'avais les backups heureusement), je n'ai pas réussi à faire une installation ZFS rapidement, et pour débloquer, j'ai repris l'install OVH en RAID soft.
Proxmox fait les backups 1x par semaine (en "suspend"), comme pour tous mes autres conteneurs.
À part Ubuntu 22.04 et MariaDB, c'est une config assez standard dans mes conteneurs.
Mes autres conteneurs sont en 20.04 ou 18.04 (je dois les upgrader ou migrer les sites), toujours avec Virtualmin / Webmin et PHP-FPM, mais avec MySQL.
Merci
Bonjour Christophe.
Franchement, je ne vois pas grand choses…
Même si j'ai appliqué une ligne de conf dans Apache pour les timeout, ça n'explique pas que MariaDB bloque quand je tape "reboot"
Comment je vérifie le cache mémoire ?
Les disques : je peux lancer des tests sur les 2 NMVe, mais je dois voir comment, car smartctl ne semble pas optimum pour tester des NVMe.
Comme je l'ai écrit, j'ai 4 GB de RAM.
La plupart de mes conteneurs tournent avec 4 GB de ram, et les serveurs mails avec 3 GB de ram.
Mais je peux augmenter la RAM sans problème.
Le serveur Proxmox a de la réserve en Ram et cpu en général.
Remarque aussi, j'ai un conteneur MUNIN.
C'est vrai que ça charge le serveur Proxmox régulièrement toutes les 5 minutes…
Mais… ça fait des années que ça tourne comme cela.
Les tests disques : je vais attendre d'avoir vérifier que j'ai bien sauvé tous mes backups récents sur le FTP OVH mais aussi sur un autre serveur.
Avant de toucher au RAID, je vais être prudent et recopier mes backups.
Mais je peux les faire. ça permettrait de vérifier si c'est, ou pas, un problème disque.
Je vais remettre à jour et rebooter tous mes autres conteneurs, car si c'est un problème disque, je trouve étrange que je n'ai jamais eu ce problème de blocage site sur un timeout PHP-FPM ni de blocage sur reboot sur MariaDB !
Mes autres sites utilisaient MySQL… mais en théorie c'est très proche de MariaDB.
Merci
c'est une stack avec du PHP-FPM ?
Si oui est-ce le "pm.max_children" sature ? (voir phpX.X-fpm.log si comme debian)
C'est possible !
J'ai vu ce genre de post également, mais je n'ai pas trouvé où était ou devrait être cette ligne **pm.max_children** ?
Je vais refaire des recherche avec "**phpX.X-fpm.log**"
Backup Proxmox ?
Il y a eu effectivement un backup Proxmox (suspend) ce samedi vers 2H du matin.
Lié ou pas, je ne sais pas, mais les 2 sites sont down à des heures différentes, 6h39 et 9h33.
Pas eu de backup automatique samedi soir ou ce dimanche.
Intéressant ton lien vers le forum Proxmox...
Donc,il y aurait un problème avec le **backup** d' Ubuntu 20.04 ou 22.04 avec **MariaDB** ?
Là, c'était avec Debian 11, mais ça pourrait être identique :
https://jira.mariadb.org/browse/MDEV-27196
ça pourrait être le backup !
Bonjour,
J'ai vu ce genre de post également, mais je n'ai pas trouvé où était ou devrait être cette ligne pm.max_children ?
dans la config de la pool PHP.
Il y a eu effectivement un backup Proxmox (suspend) ce samedi vers 2H du matin.
Lié ou pas, je ne sais pas, mais les 2 sites sont down à des heures différentes, 6h39 et 9h33.
que disent les logs de backup & syslog au moment du backup ?
à part éventuellement une saturation PHP-FPM qui continue d'écrire du SQL au moment de reboot je vois pas trop.
Surtout que là avec l'installation OVH, le support proxmox c'est mort et vu que c'est un CT cela ne peut pas être le bug qemu-agent (pas d'agent pour un CT + le fait qu'il soit en mode "suspend").
La seule solution que je vois : passer les logs MariaDB en verbosité maximal et regarder les logs (MariaDB & syslog) au moment d'un reboot.
Cordialement, janus57
config de la pool PHP ?
Syslog, oui j'allais les vérifier !
Pas eu le temps hier.
Les logs backup, j'avoue ne jamais avoir regardé.
Saturation PHP-FPM qui écrit au moment du reboot, mais alors pourquoi je n'ai jamais eu ça avec mes conteneurs 18.04 et 20.04 ?
Ils étaient déjà en PHP-FPM.
Merci
c'est une stack avec du PHP-FPM ?
Si oui est-ce le "pm.max_children" sature ? (voir phpX.X-fpm.log si comme debian)
ça se pourrait !
/var/log# less php8.1-fpm.log
[21-Aug-2022 00:00:16] NOTICE: error log file re-opened
[21-Aug-2022 03:16:13] NOTICE: Terminating ...
[21-Aug-2022 03:16:13] NOTICE: exiting, bye-bye!
[21-Aug-2022 03:16:13] NOTICE: fpm is running, pid 91177
[21-Aug-2022 03:16:13] NOTICE: ready to handle connections
[21-Aug-2022 03:16:13] NOTICE: systemd monitor interval set to 10000ms
[21-Aug-2022 03:42:56] WARNING: [pool 1660682835135478] server reached pm.max_children setting (20), consider raising it
[21-Aug-2022 05:38:57] NOTICE: Terminating ...
[21-Aug-2022 05:38:57] NOTICE: exiting, bye-bye!
[21-Aug-2022 05:39:10] NOTICE: fpm is running, pid 110918
[21-Aug-2022 05:39:10] NOTICE: ready to handle connections
[21-Aug-2022 05:39:10] NOTICE: systemd monitor interval set to 10000ms
[21-Aug-2022 05:40:46] NOTICE: Terminating ...
[21-Aug-2022 05:40:46] NOTICE: exiting, bye-bye!
[21-Aug-2022 05:45:27] NOTICE: fpm is running, pid 189
[21-Aug-2022 05:45:27] NOTICE: ready to handle connections
[21-Aug-2022 05:45:27] NOTICE: systemd monitor interval set to 10000ms
**server reached pm.max_children setting**
Bonjour,
config de la pool PHP ?
oui, la configuration de la pool PHP ou l'on défini si c'est une pool static/dynamic/ondemand etc.
Saturation PHP-FPM qui écrit au moment du reboot, mais alors pourquoi je n'ai jamais eu ça avec mes conteneurs 18.04 et 20.04 ?
cette phrase serait valide seulement si on parle du même container qui était dans des versions précédentes. Actuellement vos autre container en 18.04 et 20.04 n'ont peut être pas la même charge charge ou profile de charge que le container en 22.04 et surtout n'ont pas les mêmes version logiciel (systemd/mariadb/php/apache etc.).
Pour vérifier que c'est bien un problème de CT en Ubuntu 22.04 il faudrait en créer un vierge, importer des data de tests dans la BDD (genre : https://github.com/datacharmer/test_db) et vérifier si le problème est le même avec simplement MariaDB dans un CT.
Si le problème n'est pas reproductible alors il y a autre chose dans le CT qui pose problème.
Pour ma part n'utilisant jamais les container en prod je ne pourrais pas en dire plus sur la partie CT.
J'utilise que des VM (aucune coupure lors d'une migration dynamique comparé à un CT) avec les recommandations proxmox pour les installation (dans mon cas un RAID1 en ZFS chez OVH).
Cordialement, janus57
Samedi matin :
/var/log# less php8.1-fpm.log.1
[20-Aug-2022 07:02:21] WARNING: [pool 166044061334172] server reached pm.max_children setting (20), consider raising it
[20-Aug-2022 09:18:06] WARNING: [pool 1660682835135478] server reached pm.max_children setting (20), consider raising it
UptimeRobot me signe le 1er site down à 6h39 … ? et le 2ème à 9h33
Les heures ne correspondent pas pour le 1er site…
-------------------------
syslog.
ça doit être +/- à ce moment que j'ai tapé le "reboot"
Aug 21 05:40:31 ct822-drupal systemd[1]: Stopping The Apache HTTP Server…
Aug 21 05:40:31 ct822-drupal systemd[1]: apache2.service: Deactivated successfully.
Aug 21 05:40:31 ct822-drupal systemd[1]: Stopped The Apache HTTP Server.
Aug 21 05:40:46 ct822-drupal systemd[1]: Stopping The PHP 8.1 FastCGI Process Manager…
Aug 21 05:40:46 ct822-drupal systemd[1]: php8.1-fpm.service: Deactivated successfully.
Aug 21 05:40:46 ct822-drupal systemd[1]: Stopped The PHP 8.1 FastCGI Process Manager.
Aug 21 05:41:25 ct822-drupal systemd[1]: Stopping MariaDB 10.6.7 database server…
Aug 21 05:41:25 ct822-drupal mariadbd[287]: 2022-08-21 5:41:25 0 [Note] /usr/sbin/mariadbd (initiated by: unknown): Normal shutdown
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1771 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1768 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1752 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1748 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1744 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1727 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1721 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1719 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1710 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1682 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1654 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1640 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1634 (user : 'monsite1') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1610 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1608 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1606 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1605 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1604 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1603 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1602 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1601 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1600 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1599 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1598 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1597 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1596 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1595 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1593 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1590 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1587 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1577 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1568 (user : 'monsite2') did not exit
Aug 21 05:41:45 ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1550 (user : 'monsite2') did not exit
Aug 21 05:43:16 ct822-drupal systemd[1]: Removed slice Slice /system/modprobe.
Aug 21 05:43:16 ct822-drupal systemd[1]: Removed slice Slice /system/ssh.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped target Graphical Interface.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped target Multi-User System.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped target Login Prompts.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped target Remote Encrypted Volumes.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped target Remote Verity Protected Volumes.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped target Timer Units.
Aug 21 05:43:16 ct822-drupal systemd[1]: apt-daily-upgrade.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Daily apt upgrade and clean activities.
Aug 21 05:43:16 ct822-drupal systemd[1]: apt-daily.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Daily apt download activities.
Aug 21 05:43:16 ct822-drupal systemd[1]: certbot.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Run certbot twice daily.
Aug 21 05:43:16 ct822-drupal systemd[1]: dpkg-db-backup.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Daily dpkg database backup timer.
Aug 21 05:43:16 ct822-drupal systemd[1]: e2scrub_all.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Periodic ext4 Online Metadata Check for All Filesystems.
Aug 21 05:43:16 ct822-drupal systemd[1]: etckeeper.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Daily autocommit of changes in /etc directory.
Aug 21 05:43:16 ct822-drupal systemd[1]: logrotate.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Daily rotation of log files.
Aug 21 05:43:16 ct822-drupal systemd[1]: man-db.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Daily man-db regeneration.
Aug 21 05:43:16 ct822-drupal systemd[1]: motd-news.timer: Deactivated successfully.
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopped Message of the Day.
Aug 21 05:43:16 ct822-drupal systemd[1]: Reached target Unmount All Filesystems.
Aug 21 05:43:16 ct822-drupal freshclam[448]: Sun Aug 21 05:43:16 2022 -> Update process terminated
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopping ClamAV virus database updater…
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopping Console Getty…
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopping Container Getty on /dev/tty1…
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopping Container Getty on /dev/tty2…
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopping Regular background program processing daemon…
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopping Dovecot IMAP/POP3 email server…
Aug 21 05:43:16 ct822-drupal systemd[1]: Stopping Fail2Ban Service…
la configuration de la pool PHP ou l'on défini si c'est une pool static/dynamic/ondemand etc.
justement, je n'ai jamais modifié cela : static/dynamic/ondemand...
ok, j'ai trouvé où c'était :
/etc/php/8.1/fpm/pool.d# ls -lh
total 36K
-rw-r--r-- 1 root root 387 Aug 13 03:46 166035272835731.conf
-rw-r--r-- 1 root root 398 Aug 14 14:49 166044061334172.conf
-rw-r--r-- 1 root root 400 Aug 16 22:48 1660682835135478.conf
-rw-r--r-- 1 root root 21K Jul 21 14:10 www.conf
dans www.conf, il y a un
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
Mais je vois qu'il y a des config par site :
# vi 1660682835135478.conf
[1660682835135478]
user = monsite2
group = monsite2
listen.owner = monsite2
listen.group = monsite2
listen.mode = 0660
listen = /var/php-fpm/1660682835135478.sock
pm = dynamic
pm.max_children = 20
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 5
php_value[upload_tmp_dir] = /home/monsite2/tmp
php_value[session.save_path] = /home/monsite2/tmp
php_value[max_execution_time] = 40
et j'ai donc enfin trouvé où était ce pm.max_children !
C'est trop bas tu crois ?
Bonjour,
UptimeRobot me signe le 1er site down à 6h39 … ? et le 2ème à 9h33
Les heures ne correspondent pas pour le 1er site…
le CT est bien à l'heure ?
C'est trop bas tu crois ?
faut ajuster en fonction de la charge du site, impossible à répondre de manière générale.
Mais à titre d'exemple, quand je déploie un nextcloud, le pm.max_children est à 100 minimum.
Par contre faut ajuster par le panel et non directement dans le fichier, sinon le panel va reset la valeur.
ct822-drupal mariadbd[287]: 2022-08-21 5:41:45 0 [Warning] /usr/sbin/mariadbd: Thread 1550 (user : 'monsite2') did not exit
alors pour ça il serait intéressant de faire un stop du service mariadb tout en regardant les logs de systemd pour voir ce que mariadb fait exactement, mais il doit surement essayer de décharger sa mémoire sur le disque avec peut être des transactions qui sont en cours de finalisations.
<br />systemctl stop mariadb.service<br />journalctl -f -u mariadb.service<br />de mon coté avec la config par défaut de Debian (serveur de test) cela donne :
<br />:~# journalctl -f -u mariadb.service<br />-- Journal begins at Fri 2021-10-08 20:10:01 CEST. --<br />juil. 26 21:57:02 srv-test01 /etc/mysql/debian-start[1988468]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck<br />juil. 26 21:57:02 srv-test01 /etc/mysql/debian-start[1988468]: This installation of MariaDB is already upgraded to 10.5.12-MariaDB.<br />juil. 26 21:57:02 srv-test01 /etc/mysql/debian-start[1988468]: There is no need to run mysql_upgrade again for 10.5.15-MariaDB.<br />juil. 26 21:57:02 srv-test01 /etc/mysql/debian-start[1988468]: You can use --force if you still want to run mysql_upgrade<br />juil. 26 21:57:02 srv-test01 /etc/mysql/debian-start[1988509]: Triggering myisam-recover for all MyISAM tables and aria-recover for all Aria tables<br />août 03 22:03:08 srv-test01 mariadbd[1988444]: 2022-08-03 22:03:08 7291 [Warning] Aborted connection 7291 to db: 'cms' user: 'cms' host: 'localhost' (Got an error reading communication packets)<br />août 03 22:03:09 srv-test01 mariadbd[1988444]: 2022-08-03 22:03:09 7292 [Warning] Aborted connection 7292 to db: 'cms' user: 'cms' host: 'localhost' (Got an error reading communication packets)<br />août 11 12:07:48 srv-test01 mariadbd[1988444]: 2022-08-11 12:07:48 14669 [Warning] Aborted connection 14669 to db: 'cms' user: 'cms' host: 'localhost' (Got an error reading communication packets)<br />août 11 16:48:11 srv-test01 mariadbd[1988444]: 2022-08-11 16:48:11 14816 [Warning] Aborted connection 14816 to db: 'cms' user: 'cms' host: 'localhost' (Got an error reading communication packets)<br />août 11 16:48:11 srv-test01 mariadbd[1988444]: 2022-08-11 16:48:11 14815 [Warning] Aborted connection 14815 to db: 'cms' user: 'cms' host: 'localhost' (Got an error reading communication packets)<br />août 21 18:44:21 srv-test01 systemd[1]: Stopping MariaDB 10.5.15 database server...<br />août 21 18:44:21 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:21 0 [Note] /usr/sbin/mariadbd (initiated by: unknown): Normal shutdown<br />août 21 18:44:21 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:21 0 [Note] Event Scheduler: Purging the queue. 0 events<br />août 21 18:44:21 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:21 0 [Note] InnoDB: FTS optimize thread exiting.<br />août 21 18:44:21 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:21 0 [Note] InnoDB: Starting shutdown...<br />août 21 18:44:21 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:21 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool<br />août 21 18:44:21 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:21 0 [Note] InnoDB: Buffer pool(s) dump completed at 220821 18:44:21<br />août 21 18:44:22 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:22 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"<br />août 21 18:44:22 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:22 0 [Note] InnoDB: Shutdown completed; log sequence number 985416365; transaction id 5849430<br />août 21 18:44:22 srv-test01 mariadbd[1988444]: 2022-08-21 18:44:22 0 [Note] /usr/sbin/mariadbd: Shutdown complete<br />août 21 18:44:22 srv-test01 systemd[1]: mariadb.service: Succeeded.<br />août 21 18:44:22 srv-test01 systemd[1]: Stopped MariaDB 10.5.15 database server.<br />août 21 18:44:22 srv-test01 systemd[1]: mariadb.service: Consumed 27min 58.501s CPU time.<br />Cordialement, janus57
Bonjour Janus
le CT est automatiquement à l'heure.
par défaut il prend son heure sur le serveur Proxmox, qui est en NTP sur plusieurs serveurs.
Je viens de vérifier, le ct est à l'heure.
faut ajuster en fonction de la charge du site, impossible à répondre de manière générale.
Mais à titre d'exemple, quand je déploie un nextcloud, le pm.max_children est à 100 minimum.
Alors, oui, mes valeurs sont faibles !
Je peux essayer de monter le pm.max_children de chaque site de 20 à 60 ou 100…
---------------
Pour les backups, si j'ai encore le problème (je ne sais pas si c'est lié), je peux changer le backup mode de "suspend" en "halt" .
Un peu con de faire un stop du conteneur, mais je préfère un stop / start de ces sites moyennement critiques pendant 3 minutes 1x par semaine (à mon avis, PAS critique à 2h du mat) et ne (peut-être) plus avoir de blocage ?
Merci