Discussion:
Apache vraagje
(te oud om op te antwoorden)
Paul van der Vlis
2024-08-01 13:23:35 UTC
Permalink
Hallo allen,

Een nogal verouderde website is traag. Maar als ik de php-fpm.service
herstart dan is hij wel weer snel...

Enig idee wat dat zou kunnen zijn, of hoe ik daar achter kom?
Ik heb niet zoveel ervaring met php-fpm.

Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl
Paul van der Vlis
2024-08-01 14:30:17 UTC
Permalink
Post by Paul van der Vlis
Hallo allen,
Een nogal verouderde website is traag. Maar als ik de php-fpm.service
herstart dan is hij wel weer snel...
Het blijkt niet lang te helpen.

Deze machine heeft maar 2 cores, en de load is vaak 8 0f 9 of zoiets,
veel te hoog dus.

Op de VM draait eigenlijk maar 1 site, hij heeft 4GB geheugen wat
eigenlijk steeds vol zit, maar vooral buff/cache:
MiB Mem: 3915.2 total, 394.4 free, 1438.9 used, 2363.7 buff/cache
MiB Swap: 976.0 total, 648.3 free, 327.7 used. 2476.3 avail Mem

Als ik in top kijk dan valt me op dat de "wa" wat hoog is, dat is
volgens mij de IO van de schijf. Vaak iets van 70 per core:
%Cpu0: 20.1 us, 8.1 sy, 0.0 ni, 0.3 id, 71.1 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu1: 14.7 us, 7.0 sy, 0.0 ni, 2.3 id, 75.0 wa, 0.0 hi, 0.7 si, 0.3 st

Betekenis van de afkortingen:
https://unix.stackexchange.com/questions/18918/linux-top-command-what-are-us-sy-ni-id-wa-hi-si-and-st-for-cpu-usage

Ik zie een /var/lib/mysql/ibdata1 van ruim een GB. Zou het helpen de
databases te dumpen en opnieuw aan te maken met "innodb_file_per_table=1" ?

Wat zouden jullie doen?

Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl
Coen
2024-08-01 17:49:46 UTC
Permalink
Post by Paul van der Vlis
Op de VM draait eigenlijk maar 1 site, hij heeft 4GB geheugen wat
MiB Mem: 3915.2 total,   394.4 free,  1438.9 used,  2363.7 buff/cache
MiB Swap: 976.0 total,   648.3 free,   327.7 used.  2476.3 avail Mem
Als ik in top kijk dan valt me op dat de "wa" wat hoog is, dat is
%Cpu0: 20.1 us, 8.1 sy, 0.0 ni, 0.3 id, 71.1 wa, 0.0 hi, 0.3 si,  0.0 st
%Cpu1: 14.7 us, 7.0 sy, 0.0 ni, 2.3 id, 75.0 wa, 0.0 hi, 0.7 si,  0.3 st
Ga maar met 'vmstat 1' kijken. Dan zal je zien dat het allemaal swap-in
en swap-out is. Disk is langzaam vergeleken met ram, en dus een hoge iowait.
Post by Paul van der Vlis
Ik zie een /var/lib/mysql/ibdata1 van ruim een GB. Zou het helpen de
databases te dumpen en opnieuw aan te maken met "innodb_file_per_table=1" ?
ibdata1 is vaak 1GB vanuit de config van MySQL/Mariadb.

Dumpen en reloaden zal iets helpen, maar niet meer dan een optimize op
een table. 4GB is op een server met Apache, PHP en Mysql vaak te weinig.

Een php-fpm proces voor WordPress of vergelijkbaar pakt vaak al snel
512MB. MySQL afhankelijk van tuning 1GB of meer.

Dit soort dingen zijn in hosting-land dagelijkse kost.
Paul van der Vlis
2024-08-01 18:32:03 UTC
Permalink
Post by Coen
Post by Paul van der Vlis
Op de VM draait eigenlijk maar 1 site, hij heeft 4GB geheugen wat
MiB Mem: 3915.2 total,   394.4 free,  1438.9 used,  2363.7 buff/cache
MiB Swap: 976.0 total,   648.3 free,   327.7 used.  2476.3 avail Mem
Als ik in top kijk dan valt me op dat de "wa" wat hoog is, dat is
%Cpu0: 20.1 us, 8.1 sy, 0.0 ni, 0.3 id, 71.1 wa, 0.0 hi, 0.3 si,  0.0 st
%Cpu1: 14.7 us, 7.0 sy, 0.0 ni, 2.3 id, 75.0 wa, 0.0 hi, 0.7 si,  0.3 st
Ga maar met 'vmstat 1' kijken. Dan zal je zien dat het allemaal swap-in
en swap-out is. Disk is langzaam vergeleken met ram, en dus een hoge iowait.
Ik zie dan zoiets:
--------
***@bdj:~# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
r b swpd free buff cache si so bi bo in cs us sy
id wa st
2 1 338932 471056 458256 1977808 1 3 26265 485 2417 4059 29
9 4 58 0
3 1 338932 471056 458256 1977808 0 0 18928 45 2335 3890 32
9 40 19 1
2 2 338932 471056 458256 1977808 0 0 10432 2 1760 2338 61
15 3 11 10
1 1 338932 471056 458256 1977808 0 0 21264 2 2420 3501 32
5 26 36 0
---------

Wellicht betekent dat hij veel met swappen bezig is, maar weet het niet
zeker. Is het wijzigen van de swappiness nog een goed idee?
Post by Coen
Post by Paul van der Vlis
Ik zie een /var/lib/mysql/ibdata1 van ruim een GB. Zou het helpen de
databases te dumpen en opnieuw aan te maken met
"innodb_file_per_table=1" ?
ibdata1 is vaak 1GB vanuit de config van MySQL/Mariadb.
Dumpen en reloaden zal iets helpen, maar niet meer dan een optimize op
een table. 4GB is op een server met Apache, PHP en Mysql vaak te weinig.
Een php-fpm proces voor WordPress of vergelijkbaar pakt vaak al snel
512MB. MySQL afhankelijk van tuning 1GB of meer.
Zoals gezegd staat er maar 1 productiesite op (Magento 1.x, EOL..).
Uiteraard heb ik OpenMage aangeraden, maar dat willen ze niet. Een
eerdere migratie door iemand anders had veel geld gekost, en was niet
gelukt.
Post by Coen
Dit soort dingen zijn in hosting-land dagelijkse kost.
Ik gebruik mpm-itk, maar overweeg ook weleens over te stappen op FPM.

Maar als ik het goed begrijp denk jij dat uitbreiden van het geheugen de
beste oplossing is?

Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl
Coen
2024-08-01 20:34:03 UTC
Permalink
Post by Paul van der Vlis
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
id wa st
 2  1 338932 471056 458256 1977808    1    3 26265   485 2417 4059 29
9  4 58  0
 3  1 338932 471056 458256 1977808    0    0 18928    45 2335 3890 32 9
40 19  1
 2  2 338932 471056 458256 1977808    0    0 10432     2 1760 2338 61
15  3 11 10
 1  1 338932 471056 458256 1977808    0    0 21264     2 2420 3501 32 5
26 36  0
---------
Wellicht betekent dat hij veel met swappen bezig is, maar weet het niet
zeker. Is het wijzigen van de swappiness nog een goed idee?
Opmaak in puin door mijn quote, maar si/so is swap-in en swap-out, en
dat is zo te zien vrijwel nul?

Wel is er een behoorlijk io-bytes-in. Dat zou volgens mijn man page in K
moeten zijn. En dan hebben we het dus over een constante read-rate van
~20MB per seconde?

Kan je eens met iostat -d -k 1 kijken waar dat vandaan komt?

Eigenlijk wil dan ook met iotop gaan kijken welk proces het is. Maar dat
is niet een heel erg standaard util.

Swapiness doet niet heel erg veel.
Is leuk als je veel genoeg geheugen hebt en af en toe wat delay voor een
process wat na een lange periode van slaap weer geladen moet worden.

Magento is nogal een behoorlijke berg php code die voor elk request
verwerkt moet worden. Hoe zit het met zaken als als opcache?
Paul van der Vlis
2024-08-02 11:39:42 UTC
Permalink
Post by Coen
Post by Paul van der Vlis
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us
sy id wa st
  2  1 338932 471056 458256 1977808    1    3 26265   485 2417 4059 29
9  4 58  0
  3  1 338932 471056 458256 1977808    0    0 18928    45 2335 3890 32
9 40 19  1
  2  2 338932 471056 458256 1977808    0    0 10432     2 1760 2338 61
15  3 11 10
  1  1 338932 471056 458256 1977808    0    0 21264     2 2420 3501 32
5 26 36  0
---------
Wellicht betekent dat hij veel met swappen bezig is, maar weet het
niet zeker. Is het wijzigen van de swappiness nog een goed idee?
Opmaak in puin door mijn quote,
Valt mee..
Post by Coen
maar si/so is swap-in en swap-out, en
dat is zo te zien vrijwel nul?
Inderdaad...
Post by Coen
Wel is er een behoorlijk io-bytes-in. Dat zou volgens mijn man page in K
moeten zijn. En dan hebben we het dus over een constante read-rate van
~20MB per seconde?
Dat is veel..
Post by Coen
Kan je eens met iostat -d -k 1 kijken waar dat vandaan komt?
De load is nu wat lager, maar ik zie dit soort dingen:
------
Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read
kB_wrtn kB_dscd
dm-0 3471.00 55488.00 5.00 0.00 55488
5 0
dm-1 0.00 0.00 0.00 0.00 0
0 0
vda 3470.00 55472.00 5.00 0.00 55472
5 0

Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read
kB_wrtn kB_dscd
dm-0 4251.00 56496.00 3224.50 0.00 56496
3224 0
dm-1 0.00 0.00 0.00 0.00 0
0 0
vda 4231.00 56512.00 3128.50 0.00 56512
3128 0
------
Post by Coen
Eigenlijk wil dan ook met iotop gaan kijken welk proces het is. Maar dat
is niet een heel erg standaard util.
Daar komt zoiets uit, veel MariaDB:
-----
Total DISK READ: 22.20 M/s | Total DISK WRITE: 307.08 K/s
Current DISK READ: 22.18 M/s | Current DISK WRITE: 139.07 K/s
TID PRIO USER DISK READ DISK WRITE> COMMAND

230 be/4 root 0.00 B/s 182.94 K/s systemd-journald
178 be/3 root 0.00 B/s 41.07 K/s [jbd2/dm-0-8]
107182 be/4 bdj-jard 0.00 B/s 3.73 K/s php-fpm: pool klant.com
1294 be/4 mysql 17.94 M/s 955.77 B/s mariadbd
1 be/4 root 0.00 B/s 0.00 B/s init
2 be/4 root 0.00 B/s 0.00 B/s [kthreadd]
3 be/0 root 0.00 B/s 0.00 B/s [rcu_gp]
4 be/0 root 0.00 B/s 0.00 B/s [rcu_par_gp]
------
Post by Coen
Swapiness doet niet heel erg veel.
Is leuk als je veel genoeg geheugen hebt en af en toe wat delay voor een
process wat na een lange periode van slaap weer geladen moet worden.
Magento is nogal een behoorlijke berg php code die voor elk request
verwerkt moet worden. Hoe zit het met zaken als als opcache?
In 10.opcache.ini staat alleen zoiets:
zend_extension=opcache.so

Lijkt dus niet geconfigureerd. Wellicht zoiets eronder zetten?

opcache.save_comments=1
opcache.revalidate_freq=60
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=20000

Heel erg bedankt voor je ondersteuning overigens!

Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl
Coen
2024-08-02 17:58:37 UTC
Permalink
Post by Paul van der Vlis
------
Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read
   kB_wrtn    kB_dscd
dm-0           3471.00     55488.00         5.00         0.00      55488
         5          0
dm-1              0.00         0.00         0.00         0.00          0
         0          0
vda            3470.00     55472.00         5.00         0.00      55472
         5          0
Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read
   kB_wrtn    kB_dscd
dm-0           4251.00     56496.00      3224.50         0.00      56496
      3224          0
dm-1              0.00         0.00         0.00         0.00          0
         0          0
vda            4231.00     56512.00      3128.50         0.00      56512
      3128          0
------
-----
Total DISK READ:        22.20 M/s | Total DISK WRITE:       307.08 K/s
Current DISK READ:      22.18 M/s | Current DISK WRITE:     139.07 K/s
    TID  PRIO  USER     DISK READ DISK WRITE>    COMMAND
    230 be/4 root        0.00 B/s  182.94 K/s systemd-journald
    178 be/3 root        0.00 B/s   41.07 K/s [jbd2/dm-0-8]
 107182 be/4 bdj-jard    0.00 B/s    3.73 K/s php-fpm: pool klant.com
   1294 be/4 mysql      17.94 M/s  955.77 B/s mariadbd
      1 be/4 root        0.00 B/s    0.00 B/s init
      2 be/4 root        0.00 B/s    0.00 B/s [kthreadd]
      3 be/0 root        0.00 B/s    0.00 B/s [rcu_gp]
      4 be/0 root        0.00 B/s    0.00 B/s [rcu_par_gp]
------
3400 iops. Om het even in perspectief te zetten, vroeger toen ik nog
haar had, had je daar 20 disks van 15krpm (De snelle dure) voor nodig
met een goede raid controller.

Heel veel reads betekend dat de data-set niet in het geheugen van
Mariadb past. Als het innodb tables zijn, dan zou je naar de
innodb-buffer-pool-size kunnen kijken. Maar pas op *! (Als het geen
Innodb tables zijn heb je zowieso een uitdaging)

https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-resize.html
Post by Paul van der Vlis
zend_extension=opcache.so
Lijkt dus niet geconfigureerd. Wellicht zoiets eronder zetten?
opcache.save_comments=1
opcache.revalidate_freq=60
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=20000
Dat klinkt goed. Het is wat lastig inschatten, maar wat spelen met de
waardes helpt altijd wel.
Je kan dit proberen op een afgeschermde pagina:
https://github.com/rlerdorf/opcache-status

Ik zie dat die al wel echt oud is, dus werkt misschien niet meer.
Ook weet ik niet hoe Opcache omgaat met ITK. Blijven die threads
tussendoor draaien?

Waar ik bij de innodb-buffer-pool-size al even op hintte: Zowel Innodb
settings als Opcache gaan je geheugen gebruik verhogen. Als je te ver
gaat dan ga je behalve veel lezen ook nog veel swappen en dan kom je
alleen maar dieper in de put te zitten :)

Als je ruimte hebt om die 4GB te verdubbelen dan krijg je wat lucht voor
verbetering. Tot die tijd zul je heel goed moeten kijken en steeds meten
hoe je er voor staat.

Loading...