Linux, free, et phpSysInfo

Marsh Posté le 03-12-2002 à 22:08:58

:hello:

Je viens chercher un peu d'aide, car je rencontre des soucis de perfs avec un serveur Web, et Linux c'est pas ma tasse de thé. Ca concerne une petite machine équipée de seulement 128 Mo de RAM. Jusqu'alors je ne m'en étais pas trop soucié, d'autant plus que le script phpSysInfo (http://phpsysinfo.sourceforge.net) m'indique quelque soit la charge machine qu'il y a au minimum 50% de mémoire libre (58.19 Mo de libre et 64.85 Mo d'utilisé, sur un total de 123.04 Mo).

Seulement, avec la fréquentation des sites qui sont hébergés sur cette machine qui augmente, il y a régulièrement des pics de charge. Et c'est là que je me suis apercu que free ne me donne pas du tout les mêmes valeurs :

total used free shared buffers cached
Mem: 125992 122064 3928 0 4488 30816
-/+ buffers/cache: 86760 39232
Swap: 265064 34612 230452

Quelqu'un sait de quelle manière phpSysInfo calcule la RAM libre ? Car là la différence est énorme. Sur un serveur en production, je suppose que la RAM réellement libre est plus de 4 Mo que de 58 ?

Si ca intéresse quelqu'un, voici à quoi ressemble la fonction PHP qui retourne la quantité de RAM libre de phpSysInfo, si on l'isole :

Code :

function ressources_memoire () {
if ($fd = fopen('/proc/meminfo', 'r')) {
while ($buf = fgets($fd, 4096)) {
if (preg_match('/Mem:\s+(.*)$/', $buf, $ar_buf)) {
$ar_buf = preg_split('/\s+/', $ar_buf[1], 6);
$results['ram'] = array();
$results['ram']['total'] = $ar_buf[0] / 1024;
$results['ram']['used'] = $ar_buf[1] / 1024;
$results['ram']['free'] = $ar_buf[2] / 1024;
$results['ram']['shared'] = $ar_buf[3] / 1024;
$results['ram']['buffers'] = $ar_buf[4] / 1024;
$results['ram']['cached'] = $ar_buf[5] / 1024;
$results['ram']['t_used'] = $results['ram']['used'] - $results['ram']['cached'] - $results['ram']['buffers'];
$results['ram']['t_free'] = $results['ram']['total'] - $results['ram']['t_used'];
$results['ram']['percent'] = round(($results['ram']['t_used'] * 100) / $results['ram']['total']);
}
}
fclose($fd);
} else {
$results['ram'] = array();
$results['swap'] = array();
$results['devswap'] = array();
}
return $results;
}

Au regard du "top" suivant, vous pensez que c'est plus une insuffisance du CPU qui charge la machine, ou simplement un problème de RAM ?

9:45pm up 7:23, 1 user, load average: 2,28, 3,13, 3,43
126 processes: 121 sleeping, 5 running, 0 zombie, 0 stopped
CPU states: 23,0% user, 23,4% system, 0,0% nice, 53,4% idle
Mem: 125992K av, 121460K used, 4532K free, 0K shrd, 6040K buff
Swap: 265064K av, 33728K used, 231336K free 32876K cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
5235 nobody 17 0 5212 4788 3868 R 8,4 3,8 0:00 httpd
5860 mysql 17 0 12648 10M 9240 R 7,5 8,7 0:00 mysqld
5855 root 15 0 1076 1072 816 R 5,6 0,8 0:00 top
4975 nobody 13 0 4944 4428 3512 R 3,7 3,5 0:00 httpd
5648 nobody 10 0 4764 4344 3444 S 2,8 3,4 0:00 httpd
5210 nobody 9 0 5404 4984 3968 S 1,8 3,9 0:00 httpd
5217 nobody 10 0 5072 4652 3588 S 1,8 3,6 0:00 httpd
5292 nobody 11 0 4892 4468 3496 S 1,8 3,5 0:00 httpd
467 named 10 0 9684 1628 1408 S 0,9 1,2 0:02 named
5146 nobody 10 0 5516 5040 4112 S 0,9 4,0 0:01 httpd
5257 nobody 9 0 5432 5012 3824 S 0,9 3,9 0:00 httpd
5400 nobody 10 0 5240 4816 3864 S 0,9 3,8 0:00 httpd
5629 nobody 9 0 4776 4352 3428 S 0,9 3,4 0:00 httpd
1 root 9 0 464 420 396 S 0,0 0,3 0:08 init
2 root 9 0 0 0 0 SW 0,0 0,0 0:02 keventd
3 root 19 19 0 0 0 SWN 0,0 0,0 0:07 ksoftirqd_CPU0
4 root 9 0 0 0 0 SW 0,0 0,0 1:11 kswapd
5 root 9 0 0 0 0 SW 0,0 0,0 0:00 bdflush
6 root 9 0 0 0 0 SW 0,0 0,0 0:04 kupdated
7 root -1 -20 0 0 0 SW< 0,0 0,0 0:00 mdrecoveryd
8 root 9 0 0 0 0 SW 0,0 0,0 1:24 kjournald
111 root 9 0 0 0 0 SW 0,0 0,0 1:26 kjournald
421 root 9 0 724 508 508 S 0,0 0,4 0:00 sshd
440 root 9 0 516 456 432 S 0,0 0,3 0:01 syslogd
445 root 9 0 864 372 372 S 0,0 0,2 0:00 klogd
462 named 9 0 9684 1628 1408 S 0,0 1,2 0:00 named
464 named 9 0 9684 1628 1408 S 0,0 1,2 0:03 named
465 named 9 0 9684 1628 1408 S 0,0 1,2 0:27 named
466 named 9 0 9684 1628 1408 S 0,0 1,2 0:00 named
594 root 9 0 636 476 476 S 0,0 0,3 0:00 xinetd
610 qmails 9 0 340 256 256 S 0,0 0,2 0:04 qmail-send
611 qmaill 9 0 320 256 256 S 0,0 0,2 0:01 multilog
612 root 14 0 416 360 344 S 0,0 0,2 0:02 tcpserver
613 qmaill 8 0 420 352 352 S 0,0 0,2 0:00 tcpserver

Merci d'avance à ceux qui auront le temps de me tuyauter

Reply

Marsh Posté le 03-12-2002 à 22:08:58

Reply

Marsh Posté le 03-12-2002 à 22:22:01

A priori, si je lis bien, tu as 30 Mo de RAM qui est en cache > apparait comme utilisé mais sera libéré par le système en cas de besoin.

Linux aime bien mettre en cache le max de RAM.

Mais je suis pas sur.

---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.

Reply

Marsh Posté le 04-12-2002 à 03:24:17

Oui c'est ça, Linux cache de la RAM pour "prévoir", mais elle est libre potentiellement pour tout programme qui demande une allocation.

phpSysInfo donne la bonne valeur car tient compte du cache ( enfin je crois que sur la 2.1 y'a le problème justement mais moi sur les antérieures c'est bon et j'ai pas essayé les suivantes )

Si le top est lors d'un pic de charge là, soit sûr que ce n'est pas le CPU, 50% d'idle c'est bon, par contre ça peut être un problème de disques durs qui ne suivent pas ? sinon la RAM c'est léger oui, mais bon faut voir l'évolution de la RAM libre/utilisée à ce moment là aussi...

Enfin ça dépend de ce que fait le site web aussi...

---------------
Fan et séquestrateur de ~~Deprem~~ De Prel Photographie, célèbre photographe de tuning automobile :o

Reply

Marsh Posté le 04-12-2002 à 04:21:30

A mon avis il faudrait suivre la charge sur une plus grande période ...
D'autres part, quel type de site web est hébergé, dynamique ou statique ?
En fait l'idéal serait d'avoir le nb de hits, voire carrément la répartition des hits par pages ...
Si tu vois que les pages les plus demandées sont les pages générées, faut pas chercher bien loin (surtout si elles font appel à pas mal de données en SGBD ... )

Message édité par Zzozo le 04-12-2002 à 04:21:56

Reply

Marsh Posté le 09-01-2003 à 21:02:22

Sly Angel a écrit :

Oui c'est ça, Linux cache de la RAM pour "prévoir", mais elle est libre potentiellement pour tout programme qui demande une allocation.

Merci pour cette réponse :jap: J'avais effectivement entendu parler de quelque chose de ce type, mais dans mon cas, est-ce qu'il est normal que j'ai 34 Mo de SWAP en ayant autant de RAM "cachée" ?

Citation :

Si le top est lors d'un pic de charge là, soit sûr que ce n'est pas le CPU, 50% d'idle c'est bon, par contre ça peut être un problème de disques durs qui ne suivent pas ?

Tu as sûrement vu juste. Je viens de surveiller attentivement top pendant un pic de charge, le CPU se tourne les pouces, avec un idle qui descent rarement en dessous de 50. Et un problème de disque me surprendrait qu'à moitié car il s'agit d'un disque IDE dont le mode DMA est désactivé au niveau du noyau (limitation imposée par l'hébergeur )

Zzozo a écrit :

A mon avis il faudrait suivre la charge sur une plus grande période ...
D'autres part, quel type de site web est hébergé, dynamique ou statique ?

C'est du 100% dynamique, tout est généré en PHP/MySQL. Mais le problème ne se situe pas au niveau des scripts, tout du moins ca m'étonnerait beaucoup, car j'ai apporté un soin tout particulier à les optimiser. Niveau PHP c'est très propre, et les requêtes SQL utilisées sont ultra courtes. D'ailleurs, machine au repos, aucune page ne prend plus de 60 ms à être générée, ce qui est correct vu la base qu'il y a derrière (5 millions d'enregistrements) et la configuration hardware relativement light (processeur Céléron, disque IDE et 128 Mo de RAM).

J'hésite vraiment à passer à 256 Mo. Le serveur est loué et je peux pas me contenter d'ajouter une barrette à 20?, il faut demander la prestation à l'hébergeur et il fait payer ca une fortune. Mais si ca peut lui donner un peu de souffle ...

Là j'ai 42 Mo de swap, avec les process suivants :

8:42pm up 37 days, 6:18, 2 users, load average: 3,86, 3,88, 3,33
127 processes: 126 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 16,9% user, 16,9% system, 0,0% nice, 66,0% idle
Mem: 125992K av, 116000K used, 9992K free, 0K shrd, 5740K buff
Swap: 265064K av, 42020K used, 223044K free 31332K cached

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 1376 80 ? S 2002 3:23 init [3]
root 2 0.0 0.0 0 0 ? SW 2002 1:47 [keventd]
root 3 0.0 0.0 0 0 ? SWN 2002 15:04 [ksoftirqd_CPU0]
root 4 0.1 0.0 0 0 ? SW 2002 102:45 [kswapd]
root 5 0.0 0.0 0 0 ? SW 2002 0:00 [bdflush]
root 6 0.0 0.0 0 0 ? SW 2002 5:58 [kupdated]
root 7 0.0 0.0 0 0 ? SW< 2002 0:00 [mdrecoveryd]
root 8 0.2 0.0 0 0 ? SW 2002 142:01 [kjournald]
root 111 0.2 0.0 0 0 ? SW 2002 155:13 [kjournald]
root 421 0.0 0.0 2748 108 ? S 2002 0:32 /usr/sbin/sshd
root 440 0.0 0.1 1448 216 ? S 2002 1:07 syslogd -m 0
root 445 0.0 0.0 1888 104 ? S 2002 0:09 klogd -2
qmails 610 0.0 0.1 1420 160 ? S 2002 4:55 qmail-send
qmaill 611 0.0 0.0 1372 96 ? S 2002 1:47 /usr/local/bin/multilog /var/log/qmail
root 612 0.0 0.0 1428 64 ? S 2002 1:19 tcpserver -H -R -c100 0 pop-3 /var/qmail/bin/qmail-popup ns3168.ovh.net /
qmaill 613 0.0 0.0 1428 52 ? S 2002 0:11 tcpserver -H -R -x /etc/tcp.smtp.cdb -c100 -u503 -g503 0 smtp /var/qmail/
qmaill 619 0.0 0.0 1352 24 ? S 2002 0:25 /usr/local/bin/tai64n
root 620 0.0 0.0 1368 80 ? S 2002 0:38 qmail-lspawn ./Maildir/
qmailr 621 0.0 0.0 1368 104 ? S 2002 0:27 qmail-rspawn
qmailq 622 0.0 0.0 1360 76 ? S 2002 0:21 qmail-clean
root 687 0.0 0.0 3616 12 ? S 2002 0:00 /usr/lib/courier-imap/libexec/authlib/authdaemond.ldap start
root 688 0.0 0.0 3616 8 ? S 2002 0:09 /usr/lib/courier-imap/libexec/authlib/authdaemond.ldap start
root 689 0.0 0.0 3616 8 ? S 2002 0:07 /usr/lib/courier-imap/libexec/authlib/authdaemond.ldap start
root 690 0.0 0.0 3616 12 ? S 2002 0:05 /usr/lib/courier-imap/libexec/authlib/authdaemond.ldap start
root 691 0.0 0.0 3616 12 ? S 2002 0:09 /usr/lib/courier-imap/libexec/authlib/authdaemond.ldap start
root 699 0.0 0.0 3616 12 ? S 2002 0:08 /usr/lib/courier-imap/libexec/authlib/authdaemond.ldap start
root 701 0.0 0.0 1604 36 ? S 2002 0:15 /usr/lib/courier-imap/libexec/couriertcpd -address=0 -stderrlogger=/usr/l
root 707 0.0 0.1 1364 160 ? S 2002 0:07 /usr/lib/courier-imap/libexec/logger imapd
root 725 0.0 0.0 1572 112 ? S 2002 1:42 crond
daemon 760 0.0 0.2 1420 316 ? S 2002 0:06 /usr/sbin/atd
root 793 0.0 1.1 1428 1428 ? SL 2002 2:45 watchdog
root 799 0.0 0.0 1352 16 ? S 2002 3:45 /usr/local/clockspeed/bin/clockspeed
root 828 0.0 0.4 8132 588 ? S 2002 3:02 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 832 0.0 0.0 1360 0 tty1 SW 2002 0:00 /sbin/mingetty tty1
root 833 0.0 0.0 1360 0 tty2 SW 2002 0:00 /sbin/mingetty tty2
root 834 0.0 0.0 1360 0 tty3 SW 2002 0:00 /sbin/mingetty tty3
root 835 0.0 0.0 1360 0 tty4 SW 2002 0:00 /sbin/mingetty tty4
root 836 0.0 0.0 1360 0 tty5 SW 2002 0:00 /sbin/mingetty tty5
root 837 0.0 0.0 1360 0 tty6 SW 2002 0:00 /sbin/mingetty tty6
root 838 0.0 0.2 2208 316 ? S< 2002 7:06 /usr/local/etc/ncftpd/ncftpd -q /usr/local/etc/ncftpd/general.cf /usr/loc
root 839 0.0 0.0 1372 0 ttyS0 SW 2002 0:00 /sbin/agetty ttyS0 9600
root 842 0.0 0.0 2008 68 ? SN 2002 0:18 /usr/local/etc/ncftpd/ncftpd -q /usr/local/etc/ncftpd/general.cf /usr/loc
root 4004 0.0 0.0 6736 0 ? SW 2002 0:00 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 24765 0.0 0.1 2148 156 ? S 2002 0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
root 30767 0.0 0.2 2264 276 ? S Jan05 0:00 /bin/sh /usr/bin/safe_mysqld --datadir=/var/lib/mysql --pid-file=/var/lib
named 18969 0.0 1.7 25848 2192 ? S Jan06 0:00 named -u named
named 18971 0.0 1.7 25848 2196 ? S Jan06 0:27 named -u named
named 18972 0.0 1.7 25848 2196 ? S Jan06 2:48 named -u named
named 18973 0.0 1.7 25848 2196 ? S Jan06 0:04 named -u named
named 18974 0.0 1.7 25848 2196 ? S Jan06 0:12 named -u named
mysql 15561 0.0 7.7 25100 9768 ? S Jan08 0:45 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-
mysql 15564 0.0 7.7 25100 9768 ? S Jan08 1:17 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-
mysql 15565 0.0 7.7 25100 9768 ? S Jan08 1:02 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-
mysql 15566 0.0 7.7 25100 9768 ? S Jan08 0:00 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-
root 23127 0.0 0.3 6232 460 ? S 19:08 0:00 /usr/sbin/sshd
root 23180 0.0 0.3 2544 452 ttyp2 S 19:08 0:00 -bash
root 26390 0.0 0.6 6276 824 ? S 19:24 0:00 /usr/sbin/sshd
root 26398 0.0 0.6 2564 876 ttyp1 S 19:24 0:00 -bash
root 31591 0.0 1.5 16776 2000 ? S 19:48 0:02 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
root 7180 0.0 0.2 2208 348 ? S< 20:30 0:00 /usr/local/etc/ncftpd/ncftpd -q /usr/local/etc/ncftpd/general.cf /usr/loc
nobody 11104 0.0 2.5 17352 3272 ? S 20:49 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12311 0.3 3.9 17432 5020 ? S 20:55 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12434 0.6 3.7 17332 4708 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12484 0.1 3.0 17440 3892 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12485 0.4 3.7 17352 4704 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12495 0.4 3.6 17380 4616 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12530 0.6 3.8 17476 4832 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12531 0.5 3.8 17444 4820 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12575 0.3 3.5 17236 4520 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12582 0.3 3.6 17356 4620 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12583 0.6 3.7 17284 4728 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12598 0.0 1.9 16832 2428 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12612 0.3 3.5 17352 4480 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12617 0.7 3.8 17320 4828 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12624 0.6 3.6 17432 4568 ? S 20:56 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12650 0.4 3.5 17480 4452 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12656 0.3 3.5 17204 4520 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12673 0.4 3.7 17520 4704 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12679 0.4 3.6 17272 4612 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12680 0.7 3.9 17384 4936 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12695 0.3 3.6 17436 4588 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12701 0.2 3.4 17172 4324 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12702 0.5 3.5 17184 4516 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12712 0.2 3.5 17412 4492 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12720 0.2 3.4 17272 4376 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12732 0.4 3.7 17544 4752 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12747 0.5 3.7 17336 4720 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12771 0.3 3.5 17376 4512 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12781 0.3 3.5 17220 4424 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12793 0.3 3.3 17168 4260 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12818 0.3 3.4 17272 4376 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12825 0.2 3.5 17484 4432 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12826 0.2 3.2 17220 4140 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12833 0.4 3.6 17420 4580 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12839 0.4 3.7 17548 4684 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12844 0.5 3.3 17168 4192 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12847 0.4 3.4 17424 4380 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12856 0.4 3.7 17540 4764 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12858 0.8 3.7 17232 4752 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12866 0.3 3.2 17188 4132 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12872 0.0 1.9 16832 2472 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12873 0.3 3.4 17448 4392 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12874 0.4 3.3 17164 4224 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12875 0.2 3.2 17164 4104 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12887 0.4 3.4 17268 4340 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12893 0.4 3.3 17232 4276 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12897 0.7 3.7 17568 4732 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12904 0.2 3.4 17420 4336 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12910 0.4 3.2 17200 4044 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12924 0.2 3.4 17388 4316 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12929 0.2 3.2 17200 4100 ? S 20:57 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12932 0.3 3.1 17172 4012 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12935 0.3 2.5 16888 3168 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12937 0.0 1.9 16832 2504 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12940 0.1 2.9 17040 3728 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12941 0.9 3.5 17592 4476 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12969 0.5 3.2 17164 4144 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12981 0.8 3.4 17400 4376 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 12987 0.3 2.9 17164 3724 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 13029 0.2 1.9 16832 2468 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 13032 0.2 1.9 16832 2468 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 13033 0.5 2.5 16940 3192 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
nobody 13035 0.1 1.9 16824 2420 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
qmailr 13039 0.0 0.6 2528 756 ? S 20:58 0:00 qmail-remote utbm.fr xxxx@xxxx.net xxxx.xxxx@xxxx.fr
nobody 13040 0.0 1.9 16832 2472 ? S 20:58 0:00 /usr/local/apache/bin/httpd -DHAVE_THROTTLE
root 13041 0.0 0.7 2836 904 ttyp1 R 20:58 0:00 ps -aux

C'est grave doc ? Cet upgrade à 256 Mo de RAM, je le demande ou pas ?

Reply

Marsh Posté le 10-01-2003 à 19:24:41

L'hébergeur, ça ne serait pas OVH des fois ? :ange: ( ça y ressemble beaucoup )

Si oui, effectivement leurs tarifs pour une upgrade sont démeusurés Ton serveur a un grosse fréquentation ? :??: Parce que même si 256 Mo pour un serveur est préférable, si c'est pas un gros site, on peut faire sans. Peut être y'a t'il moyen d'optimiser le PHP et les requêtes/structures MySQL ?

Si ça ne t'embête pas, je voudrais bien savoir la fréquentation du site et la taille ( nombre d'entrées grossomodo ) des tables SQL Tu utilises des index dans les tables MySQL ?

Y'a combien de process Apache qui tournent en moyenne ?

Essaye également les connexions à MySQL en "connect" ou en "pconnect" voir si ça change des choses niveau RAM.

sinon http://www.tonsite/server-status donne quelles stats ? ( juste la partie stats au début, pas les logs après )

Peut être qu'avec un de tous ces éléments il y a moyen d'éviter l'ajout de RAM, mais sans savoir l'activité du site c'est pas évident de te dire

---------------
Fan et séquestrateur de ~~Deprem~~ De Prel Photographie, célèbre photographe de tuning automobile :o

Reply

Marsh Posté le 10-01-2003 à 19:45:32

Cé clair que sans un suivi dans le temps on peut pas etre tre efficace quant à la direction pour agir ... Personne ne s'appelle Madame Irma et c'est pour cette raison qu'on monte des benchs et qu'on "outille" un serveur pour vérifier son comportement dans le temps ...
Pis dire que cé pas tel ou tel pb parce que au repos ca va bien ... comment dire ... :pt1cable: ... spa une démarche très "pro" ... en tout cas c'est pas une démarche permettant de mettre le doigt sur un éventuel problème ...
Instrumentes ton serveur, et fournis nous un historique de sa santé sur durée significative ... stout ..

Message édité par Zzozo le 10-01-2003 à 19:48:04

Reply

Marsh Posté le 10-01-2003 à 22:14:19

Sly Angel a écrit :

L'hébergeur, ça ne serait pas OVH des fois ? :ange: ( ça y ressemble beaucoup )

Si :ange: C'est le coût que j'évoquais pour l'upgrade de RAM, ou le bridage du DMA qui t'a mis sur la piste ?

C'est une belle saloperie ce truc en tout cas, je sais pas si c'est pour prolonger la durée de vie des disques ou pour inciter les clients à passer sur du SCSI qu'ils font ca mais c'est pas génial

/dev/hda1:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Invalid argument
using_dma = 0 (off)

Citation :

Si oui, effectivement leurs tarifs pour une upgrade sont démeusurés Ton serveur a un grosse fréquentation ? :??:

Il recoit pas mal de visites oui (entre 8000 et 12 000 par jour), pour un nombre de pages vues qui varie entre 150 000 et 200 000 par jour. Mais vu qu'en journée les temps de réponses s'écroulent régulièrement, je pense que beaucoup de visiteurs fuient ailleurs

Citation :

Parce que même si 256 Mo pour un serveur est préférable, si c'est pas un gros site, on peut faire sans. Peut être y'a t'il moyen d'optimiser le PHP et les requêtes/structures MySQL ? Si ça ne t'embête pas, je voudrais bien savoir la fréquentation du site et la taille ( nombre d'entrées grossomodo ) des tables SQL Tu utilises des index dans les tables MySQL ?

Pour la fréquentation du site, voir ci-dessus. La base fait 1 Go, elle est composée de 40 tables qui totalisent 5 millions d'enregistrement. Les index sont choisis avec soin, il n'y a pas une requete qui s'exécute sans les utiliser. RAS à ce niveau là Ca fait 2 ans que je travaille d'arrache pied pour les optimiser, et j'ai passé plusieurs semaines sur mysql_slow_queries.log afin d'erradiquer toute requête susceptible de s'exécuter en plus de 10ms

Citation :

Y'a combien de process Apache qui tournent en moyenne ?

Ca varie entre 60 et 65, 65 étant la valeur de MaxClients dans mon httpd.conf. Ca doit créer un sacré goulet d'étranglement (un ps auxw | grep httpd | grep -v grep | wc -l indique 65 de manière quasi-permanente), mais j'ose pas aller plus haut, vu que le serveur sature déjà.

Citation :

Essaye également les connexions à MySQL en "connect" ou en "pconnect" voir si ça change des choses niveau RAM.

Je viens de tester à l'instant, ca me laisse une cinquentaine de processus endormis. Mais l'influence sur la RAM n'a pas l'air énorme, ca semble "simplement" augmenter de 3/4 Mo le SWAP.

Citation :

sinon http://www.tonsite/server-status donne quelles stats ? ( juste la partie stats au début, pas les logs après )

Ca donne ca :

Server Version: Apache
Server Built: Oct 5 2002 20:26:49

--------------------------------------------------------------------------------
Current Time: Friday, 10-Jan-2003 21:43:20 CET
Restart Time: Friday, 10-Jan-2003 21:40:35 CET
Parent Server Generation: 2
Server uptime: 2 minutes 45 seconds
Total accesses: 3322 - Total Traffic: 2.6 MB
CPU Usage: u9.69 s5.58 cu.04 cs.02 - 9.29% CPU load
20.1 requests/sec - 16.1 kB/second - 818 B/request
65 requests currently being processed, 0 idle servers

Citation :

Peut être qu'avec un de tous ces éléments il y a moyen d'éviter l'ajout de RAM, mais sans savoir l'activité du site c'est pas évident de te dire

Oui, je comprends bien

Message édité par Core 666 le 10-01-2003 à 22:15:41

Reply

Marsh Posté le 11-01-2003 à 04:01:32

Un hébergeur qui loue du Celeron avec 128 Mo de RAM et qui pratique des tarifs abusifs sur les upgrades ça me fait tout de suite tilter

Bon, donc ton site a de la fréquentation et tu as tout bien optimisé niveau requêtes ( désolé pour les questions mais on sait jamais, j'ai souvent vu ça )

Avec autant de visites, je pense qu'il faut effectivement plus de RAM, déjà pour mieux exploiter MySQL, mais surtout surtout c'est le problème des disques durs là Je ne sais même pas si changer la RAM changera quelque chose si tu restes avec des IDE sans DMA, sur un traffic comme celui là c'est assez choquant je trouve

Je ne veux pas me méler de ce qui ne me regarde pas trop ( ton hébergement ), mais je trouve que dans ton cas il serait peut être envisageable d'acheter un serveur plutôt que de le louer et de voir peut être si c'est pas mieux ( moins cher surtout au final ) ailleurs

Sinon techniquement là, étant coincé par les IDE sans le DMA, l'idée serait d'ajouter de la RAM et de mettre le plus de choses en cache mémoire possible, mais là encore pour ça, 256 Mo seront pas suffisant pour compenser le problème

Ta charge en tout cas, c'est évident qu'elle vient des disques, parcourir autant d'entrées en continu, ça aide pas

tu peux également faire un "mysqladmin -uroot -p status" stp ?

Sinon pour Apache, rien d'anormal, c'est un peu logique d'ailleurs là

Enfin dans tous les cas je pense vraiment que le principal problème reste les disques, bien avant la RAM, ils sont saturés et ça fait augmenter la charge

P.S. : Je suppose que le kernel proposé par OVH est toujours un 2.2 non ? Sinon je pense que tes pics de charge auraient été plus impressionnants

---------------
Fan et séquestrateur de ~~Deprem~~ De Prel Photographie, célèbre photographe de tuning automobile :o

Reply

Marsh Posté le 11-01-2003 à 09:32:14

Sly Angel a écrit :

Un hébergeur qui loue du Celeron avec 128 Mo de RAM et qui pratique des tarifs abusifs sur les upgrades ça me fait tout de suite tilter

Bon, donc ton site a de la fréquentation et tu as tout bien optimisé niveau requêtes ( désolé pour les questions mais on sait jamais, j'ai souvent vu ça )

Tu m'étonnes

Citation :

Avec autant de visites, je pense qu'il faut effectivement plus de RAM, déjà pour mieux exploiter MySQL, mais surtout surtout c'est le problème des disques durs là Je ne sais même pas si changer la RAM changera quelque chose si tu restes avec des IDE sans DMA, sur un traffic comme celui là c'est assez choquant je trouve

C'est possible Au final on est pas aussi libre qu'ils se plaisent à le faire croire sur les hébergements dédiés qu'ils louent. Alors que, sur leur site, on voit partout dans les FAQ :

- Q : Est-ce que je peux faire ca ?
- R : Bien sur chez ami, tu as les droits root tu peux tout faire ^^

En plus de ce problème de DMA, la gestion de la bande passante dédiée et le bridage se fait au niveau du noyau, non au niveau des switchs qu'il y a derrière. D'après plusieurs témoignages de clients qui utilisent les mêmes offres ca créé une charge supplémentaire pour la machine, je trouve ca un peu con.

Citation :

Je ne veux pas me méler de ce qui ne me regarde pas trop ( ton hébergement ), mais je trouve que dans ton cas il serait peut être envisageable d'acheter un serveur plutôt que de le louer et de voir peut être si c'est pas mieux ( moins cher surtout au final ) ailleurs

Ca j'en suis bien conscient, mais je trouve pas de prix intéressant. OVH propose un serveur dédié en 1U avec 512 Kb de bande passante dédiée et garantie pour 9000 balles l'année, ce qui est très correct. Et j'ai beau chercher, je ne trouve pas d'hébergeur qui propose pour le même prix un emplacement 1U dans une baie et 512 Kb de bande passante dédié ... (la même offre quoi) serveur non compris

Citation :

Sinon techniquement là, étant coincé par les IDE sans le DMA, l'idée serait d'ajouter de la RAM et de mettre le plus de choses en cache mémoire possible, mais là encore pour ça, 256 Mo seront pas suffisant pour compenser le problème

Ta charge en tout cas, c'est évident qu'elle vient des disques, parcourir autant d'entrées en continu, ça aide pas

tu peux également faire un "mysqladmin -uroot -p status" stp ?

mysql> status;
--------------
mysql Ver 11.18 Distrib 3.23.54, for pc-linux (i686)

Connection id: 406536
Current database: fmdonnees
Current user: root@localhost
Current pager: stdout
Using outfile: ''
Server version: 3.23.54-log
Protocol version: 10
Connection: Localhost via UNIX socket
Client characterset: latin1
Server characterset: latin1
UNIX socket: /var/lib/mysql/mysql.sock
Uptime: 2 days 15 hours 19 min 7 sec

Threads: 1 Questions: 9717565 Slow queries: 752 Opens: 284134 Flush tables: 1 Open tables: 62 Queries per second avg: 42.631
--------------

Citation :

Sinon pour Apache, rien d'anormal, c'est un peu logique d'ailleurs là

Enfin dans tous les cas je pense vraiment que le principal problème reste les disques, bien avant la RAM, ils sont saturés et ça fait augmenter la charge

P.S. : Je suppose que le kernel proposé par OVH est toujours un 2.2 non ? Sinon je pense que tes pics de charge auraient été plus impressionnants

Non, la machine est en 2.4.18. Mais pour pas qu'elle s'emballe j'ai un script qui coupe l'accès au site quelques instants dès que le load average atteind 5. C'est pas super élégant, mais ca lui permet de souffler, et surtout ca évite de voir dans les logs que tout a été inaccessible pendant une demie-heure avec un tload de 20

Message édité par Core 666 le 11-01-2003 à 09:33:50

Reply

Marsh Posté le 11-01-2003 à 09:32:14

Reply

Marsh Posté le 12-01-2003 à 01:35:36

Ok ( tiens je faisais ça aussi y'a un temps :lol: )

Bah là le truc c'est que vraiment les disques ça fait just quoi de l'IDE sans DMA Après la RAM ça serait bien aussi de passer à 256 Mo c'est clair, mais avec les mêmes configs disque, je suis même pas sûr que tu vois une différence

Enfin voilà mon avis par rapport à tout ça, c'est assez typique comme symptome

---------------
Fan et séquestrateur de ~~Deprem~~ De Prel Photographie, célèbre photographe de tuning automobile :o

Reply

Marsh Posté le 12-01-2003 à 12:16:03

Core 666 a écrit :

qmail-remote utbm.fr xxxx@xxxx.net xxxx.xxxx@xxxx.fr

Ut Bohemien??

Reply

Linux, free, et phpSysInfo

Sujets relatifs:

Leave a Replay