La Fibre

Télécom => Logiciels et systèmes d'exploitation => Linux Linux (usage serveur) => Discussion démarrée par: vivien le 07 avril 2007 à 23:15:26

Titre: Charge d'un serveur Linux
Posté par: vivien le 07 avril 2007 à 23:15:26
46 visiteur sur le forum simultanèment ce matin, de la folie.

On a atteint une moyenne d'utilisation cpu sur 15min de 44% (load average = 0.44)
Titre: Charge d'un serveur Linux
Posté par: fgundomiel le 03 août 2011 à 14:59:44
La charge *Nix tient compte d'autres critères que l'activité processeur. Pour avoir un pourcentage d'utilisation CPÜ, utilise TOP ou HTOP.

Sur certains systèmes, une charge supérieure au nombre de CPUs met parfois en évidence les attentes périphériques (disque dur, réseau, hard/soft IRQs,etc.)

Exemple lors d'un montage de 3000 interfaces etherip en parallèle sur une machine à 8 coeurs:
(https://lafibre.info/images/bistro/201108_load_average_630.png)
Titre: Charge d'un serveur Linux
Posté par: corrector le 03 août 2011 à 18:46:27
La charge *Nix tient compte d'autres critères que l'activité processeur. Pour avoir un pourcentage d'utilisation CPÜ, utilise TOP ou HTOP.

Sur certains systèmes, une charge supérieure au nombre de CPUs met parfois en évidence les attentes périphériques (disque dur, réseau, hard/soft IRQs,etc.)
Je croyais que :
1) les processus en attentes périphériques (disque dur, réseau, hard/soft IRQs,etc.) étaient SLEEPING (ou interruptible wait)
2) top indiquait le nombre moyen de processus exécutables : RUNNING, RUNNABLE
Titre: Charge d'un serveur Linux
Posté par: vivien le 03 août 2011 à 19:19:33
Il me semblait que le load average (https://fr.wikipedia.org/wiki/Load_average) étais un indicateur plus pertinent que le % d'utilisation des CPU... "Il est un très bon indicateur de la (sur)charge de travail d'un système, mais ne permet pas d'en identifier la cause." source : wikipedia

Je précise que le load average, pour les non unixiens, c'est cet ensemble de 3 chiffres "630.82 421.14 507.16" dans la capture de fgundomiel et "7.72 4.45 1.89" dans ma capture.

Le premier chiffre une moyenne de la charge calculée sur une minute.
Le second nombre est calculé sur cinq minutes, et le troisième sur quinze minutes.

La charge représente le nombre de processus en train d'utiliser ou en train d'attendre le processeur.
Pour un usage de serveur web et afin d'être ré-actif aux demandes, il ne faut pas dépasser un load average de 1 sur un système mono-coeur, 4 sur un système équipé de 4 coeurs.

(https://lafibre.info/images/bistro/201006_load_average_lafibre.png)

(https://lafibre.info/images/bistro/201108_load_average_lafibre.png)

LaFibre.info est hébergé sur un serveur Xeon X3220 @2.40GHz équipé de 4 coeurs. Paubc.info et Digitalbitrate.com sont également hébergés sur ce serveur.
Les grandes variations de load average sont liées au site digitalbitrate.com. C'est lui qui utilise le plus le système.
Titre: Charge d'un serveur Linux
Posté par: corrector le 05 août 2011 à 11:06:36
.... pour quelle raison?
Titre: Charge d'un serveur Linux
Posté par: vivien le 05 août 2011 à 22:59:16
Petite question,

Comment savoir si le load average est élevé à cause du CPU ou des accès disque ?

Je me pose cette question pour un serveur de fichier puissant (Xeon 4 coeur X3220 @ 2.40GHz, 4 Go ram, disque dur WD Caviar Black 2 To). Logiciellement c'est Apache 2.2 worker qui délivre les fichiers (pas de PHP, pas de SQL, c'est juste délivrer des gros fichiers en http).
Je n'utilise jamais de swap.
Le serveur est relié au réseau par une connexion 2 Gb/s mais dés 800 Mb/s (200 personnes qui téléchargent chacune a 4 Mb/s), la charge augmente fortement.
Je me dit que j'arrive aux limites du disque dur mais j’aimerais bien le confirmer. Le disque dur WD Caviar Black 2 To est l'un des plus rapide disque dur SATA (hors SSD) d’après les tests, il dépasse même les performances des plusieurs disques 10 000 tr/min (mais il coûte 275€ tout de même).
Titre: Charge d'un serveur Linux
Posté par: corrector le 05 août 2011 à 23:09:55
D'après ma compréhension un disque lent doit faire baisser la charge système.
Titre: Charge d'un serveur Linux
Posté par: cali le 06 août 2011 à 00:15:25
Petite question,

Comment savoir si le load average est élevé à cause du CPU ou des accès disque ?

Je me pose cette question pour un serveur de fichier puissant (Xeon 4 coeur X3220 @ 2.40GHz, 4 Go ram, disque dur WD Caviar Black 2 To). Logiciellement c'est Apache 2.2 worker qui délivre les fichiers (pas de PHP, pas de SQL, c'est juste délivrer des gros fichiers en http).
Je n'utilise jamais de swap.
Le serveur est relié au réseau par une connexion 2 Gb/s mais dés 800 Mb/s (200 personnes qui téléchargent chacune a 4 Mb/s), la charge augmente fortement.
Je me dit que j'arrive aux limites du disque dur mais j’aimerais bien le confirmer. Le disque dur WD Caviar Black 2 To est l'un des plus rapide disque dur SATA (hors SSD) d’après les tests, il dépasse même les performances des plusieurs disques 10 000 tr/min (mais il coûte 275€ tout de même).

Salut,
Tes disques peuvent tourner à fond sans pour autant faire monter la charge processeur, tu fais un top, ça indique uniquement la charge cpu et mémoire, pour voir la charge disque tu devrais faire un iotop ou iostat. Après tu utilises apache, il faut activer le worker mod et aussi changer la valeur du nofile.
Tu devrais voir pour un passage à lighttpd ou nginx.
Titre: Charge d'un serveur Linux
Posté par: vivien le 06 août 2011 à 08:44:56
Oui, je suis bien en mode worker. J'ai vu qu'il était assez proche des perf de lighttpd ou nginx en l'absence de php ou de modules activé.

iotop répond parfaitement à mon besoin. (iotop -o -P)


iostat est fourni avec sysstat (qui est démarré toutes les 10 minutes via /etc/cron.d/sysstat)

iostat donnant des stsats depuis que le système est rebooté, c'est moins intéressant pour comprendre ce qui pose pb a un moment. Voici mes stats avec un uptime de 23 jours (je suis à 1,9 Mo/s en lecture de moyenne, les 3 Go de cache disque sont assez efficace visiblement) :

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,02    0,01    0,17    0,15    0,00   99,65

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              29,71      1855,12        87,00 3807622542  178566852



avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,02    0,00    0,25    0,31    0,00   99,41

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              36,01      2837,27       107,79 5148868874  195611592


Edit : iostat -dx /dev/sda 5 pour le temps réel

=> http://doc.ubuntu-fr.org/connaitre_son_materiel (http://doc.ubuntu-fr.org/connaitre_son_materiel)
Titre: Charge d'un serveur Linux
Posté par: cali le 06 août 2011 à 09:14:28
Bah ça va. Mais Apache est énormèment plus lent que lighttpd, nginx encore plus. Tu devrais tweaker le noyau, ceux d'ubuntu sont bourrés de modules qui servent à rien, aussi changer la fréquence de l'horloge devrait l'aider.
Titre: Charge d'un serveur Linux
Posté par: fgundomiel le 06 août 2011 à 09:19:33
Petite question,

Comment savoir si le load average est élevé à cause du CPU ou des accès disque ?

http://serverfault.com/questions/9428/how-can-i-monitor-hard-disk-load-on-linux (http://serverfault.com/questions/9428/how-can-i-monitor-hard-disk-load-on-linux)

iotop?

Citer
Je me pose cette question pour un serveur de fichier puissant (Xeon 4 coeur X3220 @ 2.40GHz, 4 Go ram, disque dur WD Caviar Black 2 To). Logiciellement c'est Apache 2.2 worker qui délivre les fichiers (pas de PHP, pas de SQL, c'est juste délivrer des gros fichiers en http).
Je n'utilise jamais de swap.
Le serveur est relié au réseau par une connexion 2 Gb/s mais dés 800 Mb/s (200 personnes qui téléchargent chacune a 4 Mb/s), la charge augmente fortement.

Quelle taille totale de contenu as-tu à fournir? Est-ce un serveur auquel tu peux accéder?

Si c'est un contenu "léger" (<12Go), je te recommande le Ramdisk, sinon, RAID 10... Autre suggestions?

Citer
Je me dit que j'arrive aux limites du disque dur mais j’aimerais bien le confirmer. Le disque dur WD Caviar Black 2 To est l'un des plus rapide disque dur SATA (hors SSD) d’après les tests, il dépasse même les performances des plusieurs disques 10 000 tr/min (mais il coûte 275€ tout de même).

FYI, les SSD ne seront pas adaptés aux usages serveurs car ils sont limités à quelques millions d'IO par blocks. Sinon, il te reste les Seagate Cheetah :p
Titre: Charge d'un serveur Linux
Posté par: fgundomiel le 06 août 2011 à 09:22:41
Et si tu es vraiment riche, double serveur avec répartion avec un smart DNS :p
Titre: Charge d'un serveur Linux
Posté par: cali le 06 août 2011 à 09:22:57
FYI, les SSD ne seront pas adaptés aux usages serveurs car ils sont limités à quelques millions d'IO par blocks. Sinon, il te reste les Seagate Cheetah :p

Aujourd'hui ça tient quand même, on est loin des 100k il y a 5 ans :p
Titre: Charge d'un serveur Linux
Posté par: vivien le 06 août 2011 à 11:23:06
C'est pour un miror Ubuntu : 461 Go de données (archives + cd + cd francisés d'ubuntu-fr + cd lubuntu) donc les SSD il faut oublier.
Je n'ai pas mis de RAID, trop cher.

Je regarderais attentivement lors du rush lors de la sortie de la prochaine version ce qui va limiter le débit.
Le but est de pouvoir servir les fichiers (n http uniquement) à un débit de 2 Gb/s lors des sorties des nouvelles version.

Même si apache consomme plus de CPU, j'ai l'impression que ce n'est vraiment pas là qu'est le goulot d'étranglement.

il faut activer le worker mod et aussi changer la valeur du nofile.

C'est à dire ?
Voici la conf que j'ai réalisé d'Apache, j'ai bien boosté les valeurs par défault :

<IfModule mpm_worker_module>
ServerLimit          32
Citer
For the worker MPM, this directive in combination with ThreadLimit sets the maximum configured value for MaxClients for the lifetime of the Apache process.
Any attempts to change this directive during a restart will be ignored, but MaxClients can be modified during a restart.
Special care must be taken when using this directive. If ServerLimit is set to a value much higher than necessary, extra, unused shared memory will be allocated.
If both ServerLimit and MaxClients are set to values higher than the system can handle, Apache may not start or the system may become unstable.
With worker, use this directive only if your MaxClients and ThreadsPerChild settings require more than 16 server processes (default).
Do not set the value of this directive any higher than the number of server processes required by what you may want for MaxClients and ThreadsPerChild.
StartServers          5
Citer
The StartServers directive sets the number of child server processes created on startup.
As the number of processes is dynamically controlled depending on the load, there is usually little reason to adjust this parameter.
MinSpareThreads      200
Citer
Minimum number of idle threads to handle request spikes.
worker use a default of MinSpareThreads 75 and deal with idle threads on a server-wide basis.
If there aren't enough idle threads in the server then child processes are created until the number of idle threads is greater than number.
MaxSpareThreads      2000
Citer
Maximum number of idle threads.
For worker the default is MaxSpareThreads 250. These MPMs deal with idle threads on a server-wide basis.
If there are too many idle threads in the server then child processes are killed until the number of idle threads is less than this number.
Worker : set the value of MaxSpareThreads to the same value as MaxClients
ThreadLimit          300
Citer
This directive sets the maximum configured value for ThreadsPerChild for the lifetime of the Apache process.
Any attempts to change this directive during a restart will be ignored, but ThreadsPerChild can be modified during a restart up to the value of this directive.
Special care must be taken when using this directive. If ThreadLimit is set to a value much higher than ThreadsPerChild, extra unused shared memory will be allocated.
If both ThreadLimit and ThreadsPerChild are set to values higher than the system can handle, Apache may not start or the system may become unstable.
Do not set the value of this directive any higher than your greatest predicted setting of ThreadsPerChild for the current run of Apache.
ThreadsPerChild      200
Citer
This directive sets the number of threads created by each child process.
The child creates these threads at startup and never creates more.
If using an MPM like worker, where there are multiple child processes, the total number of threads should be high enough to handle the common load on the server.
MaxClients          4000
Citer
The MaxClients directive sets the limit on the number of simultaneous requests that will be served.
Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive.
Once a child process is freed at the end of a different request, the connection will then be serviced.
Therefore, to increase MaxClients to a value that requires more than 16 processes, you must also raise ServerLimit
MaxRequestsPerChild   0
Citer
The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle.
After MaxRequestsPerChild requests, the child process will die.
If MaxRequestsPerChild is 0, then the process will never expire.
Worker : set the value of MaxRequestsPerChild to zero
MaxRequestsPerChild controls how frequently the server recycles processes by killing old ones and launching new ones.
</IfModule>
Titre: Charge d'un serveur Linux
Posté par: cali le 06 août 2011 à 12:22:13
Oui, ce que tu as fait sert pas, car le nofile de l'user est limité à 1024.
Titre: Charge d'un serveur Linux
Posté par: vivien le 06 août 2011 à 13:02:55
je rajoute dans /etc/security/limits.conf les 4 lignes suivantes :
*               soft    nofile          4096
*               hard    nofile          65535
root            soft    nofile          4096
root            hard    nofile          65535
ca te semble en phase avec la conf apache2 ?

Cela donne en espace utilisateur :

$ ulimit -aS
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096 (contre 1024 avant)
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


$ ulimit -aH
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65535 (contre 4096 avant)
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


$ cat /proc/sys/fs/file-max
393213


Attention :   Cette   routine   est  obsolete.  Utilisez  getrlimit(2), setrlimit(2) et sysconf(3) a la place
=> http://manpages.ubuntu.com/manpages/oneiric/fr/man3/ulimit.3.html (http://manpages.ubuntu.com/manpages/oneiric/fr/man3/ulimit.3.html)
Titre: Charge d'un serveur Linux
Posté par: cali le 06 août 2011 à 16:50:22
Il faudrait voir si c'est suffisant par rapport à ce qu'apache génère, le nombre de connexions etc...!
Titre: Charge d'un serveur Linux
Posté par: corrector le 07 août 2011 à 04:10:32
FYI, les SSD ne seront pas adaptés aux usages serveurs car ils sont limités à quelques millions d'IO par blocks.
L'architecture de mail Zimbra chez Free repose sur des SSD en RAID 1.

Yohan explique que rien d'autre qui soit abordable ne tenait la cadence : à la place de 2 SSD il aurait fallu un gros paquet de 10k RPM.

Le problème c'est qu'il est difficile de se procurer ce matériel, et que Free n'avait pas de spare; ces facteurs plus de la malchance (et certainement des bugs logiciels aussi) ont entrainé une indisponibilité des emails plus une perte de certains messages chez tous les freezimbranautes logés sur un certain serveur.

L'archi email historique (non Zimbra) de Free ne dépend pas de SSD (AFAIK).
Titre: Charge d'un serveur Linux
Posté par: vivien le 07 août 2011 à 08:17:00
OVH à mis en place (avec sucés) des SSD dans beaucoup de serveurs.

Au niveaux des serveurs de fichiers  pour l'hébergement mutualisé, ils mettent des disque dur traditionnels + des SDD qui cachent les données les plus souvent lue sur le filer. Cela permet de limiter les accès aux "vrai" disques.

Plusieurs serveurs dédies sont en vente avec uniquement des SSD.

OVH a fait pas mal de tests, et les SSD de la série 320 d'Intel sont adaptés aux serveurs.
Il n'ont pas une durée de vie infinie, mais les disque dur traditionnels non plus.

OVH re-vend en Afrique (https://lafibre.info/ovh/lignes-de-montages-ovh/msg33610/#msg33610) les disque dur traditionnels avant qu'ils tombent en panne.
Titre: Charge d'un serveur Linux
Posté par: cali le 07 août 2011 à 09:59:53
Oui mais OVH tout comme online.net sont des hébergeurs low-cost, les offres ne visent pas des utilisateurs qui vont vraiment faire l'utilisation de la puissance et de la bande passante disponible, c'est pour ça que ça coûte rien d'ailleurs. J'éviterais de prendre ça comme exemple.
Titre: Charge d'un serveur Linux
Posté par: corrector le 19 août 2011 à 00:13:16
Coté soft je n'ai pas de cache. Chaque page sur ce forum génère environ 20 requêtes SQL optimisées.
Est-ce que tu as envisagé de transformer le forum en un site statique?
Titre: Charge d'un serveur Linux
Posté par: vivien le 19 août 2011 à 07:23:59
Mon souci d'optimisation, c'est plus pour le mirror Ubuntu que je monte que pour lafibre.info

LaFibre.info va devenir dans les jours qui vienne le 1er serveur PingTest (http://www.pingtest.net/) de France.
Si la charge augmente fortement, je regarderais comment mettre en place un cache PHP.

SMF me propose le choix entre les cache / accélérateurs suivants :
- APC
- eAccelerator
- Turck MMCache
- Memcached
- Zend Platform/Performance Suite (pas Zend Optimizer)
Titre: Charge d'un serveur Linux
Posté par: Mieszko le 19 août 2011 à 09:44:29
OVH à mis en place (avec sucés) des SSD dans beaucoup de serveurs.

Au niveaux des serveurs de fichiers  pour l'hébergement mutualisé, ils mettent des disque dur traditionnels + des SDD qui cachent les données les plus souvent lue sur le filer. Cela permet de limiter les accès aux "vrai" disques.

Plusieurs serveurs dédies sont en vente avec uniquement des SSD.

OVH a fait pas mal de tests, et les SSD de la série 320 d'Intel sont adaptés aux serveurs.
Il n'ont pas une durée de vie infinie, mais les disque dur traditionnels non plus.

OVH re-vend en Afrique (https://lafibre.info/ovh/lignes-de-montages-ovh/msg33610/#msg33610) les disque dur traditionnels avant qu'ils tombent en panne.
bossant dnas le stockage (EMC), j'ai lu pas mal de docs internes qu'il n'etait clairement pas conseille de faire un stockage full SSD. Bon la ok on parle de grosses machines qui contiennent jusqu'a 2400 disques.
le prix est un frein, mais aussi la maintenance, en effet, les SSD ont une duree de vie bcp plus faible que les traditionnels disques dur.
Nous utilisons les SSD pour effectivement faire du cache dnas les machines, bien que ces dernieres soient equipees de cartes memoires consequentes qui jouent justement le role de cache (ca c'est pour les symmetrix et vmax, pour les vnx et clariion, ce sont des barettes de ram qui jouent le role de cache)
Bref, le SSD c'est bien, mais pas encore pour le stockage.
Titre: Charge d'un serveur Linux
Posté par: fgundomiel le 19 août 2011 à 12:25:08
Je suis tout à fait d'accord avec toi: sans reparler de la durée de vie, mes Cheetah 15kRPM me font pas ce genre de sales farces (https://www.nextinpact.com/actu/news/65136-ssd-force-3-force-gt-320-series-firmware.htm) ;-)

Maintenant, pour du contenu multimédia c'est galère irréalisable, mais pour des bases de données où j'ai besoin de perfs, j'ai une astuce rodée à base de ramdisk, de sauvegardes différentielles cronjobées et à l'arrêt/rédémarrage et de restauration au démarrage.
Titre: Charge d'un serveur Linux
Posté par: Mieszko le 19 août 2011 à 18:52:40
pour de la DB, je sais que chez nous il y a un produit qui a l'air de tout dechirer, Greenplum. Un des acteurs majeur de la vente en ligne en france en est equipe depuis peu et va passer en prod sous peu.
On a fait un poc (proof of concept) chez eux et visiblement les resultats etaient tres apprecies.

pour le particulier ou les petites entreprises qui ont de bonnes connaissances informatique, ton montage est ideal.