MaxClients dans apache. Comment connaître la taille de mon processus?

Depuis http://httpd.apache.org/docs/2.2/misc/perf-tuning.html

La RAM est le plus gros problème matériel affectant les performances du serveur Web. Un serveur Web ne devrait jamais avoir à échanger, car l'échange augmente la latence de chaque demande au-delà d'un point que les utilisateurs considèrent "assez rapide". Cela oblige les utilisateurs à arrêter et recharger, ce qui augmente encore la charge. Vous pouvez et devez contrôler le paramètre MaxClients afin que votre serveur ne génère pas autant d'enfants qu'il commence à échanger. Cette procédure est simple: déterminez la taille de votre processus Apache moyen, en consultant votre liste de processus via un outil tel que top, et divisez-la en votre mémoire totale disponible, en laissant de la place pour d'autres processus.

Le problème principal est que je ne comprends pas comment connaître la taille, car j'ai la taille de httpd sur plus de 3888

Mais, si nous devons déterminer le nombre de MaxClients, et que j'ai 4 Go de RAM, j'obtiens: 972, donc je devrais utiliser comme 900 dans les MaxClients?

apache-2.2 httpd

— Larry
source

"J'ai la taille de httpd sur pas plus de 3888" - Je pense que je parle pour tout le monde quand je dis "HUH?"

— womble

Réponses:

Tout d'abord, déterminez le PID de l'un de vos processus Apache.

Ensuite, vous pouvez faire quelque chose comme ceci:

cat /proc/PIDHERE/status | grep VmRSS

Cela donnera la taille (actuelle) de l'ensemble de résidents de ce processus particulier, semblable à:

VmRSS: 304456 kB

Cette valeur est telle qu'elle paraît, c'est la taille du processus résidant dans la RAM.

Normalisez ensuite votre unité de mesure ( 4GB * 1024 * 1024 = 4,194,304 KB). Diviser:

4194304 KB / 304456 KB = 13.77 processes

Considérez que vous avez probablement d'autres processus en cours d'exécution sur votre système qui consomment également de la mémoire, et idéalement, vous voulez minimiser l'échange, donc vous ne voudriez probablement pas que 13 Apache MaxClients soient configurés (en utilisant mes numéros), vous voulez un peu moins (à votre discrétion) ).

Il s'agit d'une estimation brute; la taille de vos processus Apache peut augmenter avec le temps en fonction de la charge.

— loopforever
source

Alors que RSS n'inclut pas les pages partagées, il inclut les pages marquées comme copie sur écriture - c'est-à-dire qu'il y a de l'espace sur une machine pour plus de processus que (somme des rss) / (mémoire physique). Voir aussi ma réponse ailleurs - l'espace libre est essentiel pour de bonnes performances.

— symcbean

Prédire les maxClients à partir de scénarios de test est un point de départ - mais pour résoudre correctement le problème, vous devez commencer à mesurer le comportement de votre application avec le trafic réel.

En supposant que votre apache fonctionne pré-fork ...

Configurez un travail cron pour compter le nombre de processus httpd et la sortie de «libre». Notez que si votre serveur Web fournit du contenu à partir de fichiers locaux (et dans de nombreux cas, même quand ce n'est pas le cas), la quantité de mémoire disponible pour le cache / les tampons aura un impact important sur les performances. c'est-à-dire que si vous arrivez au point de permuter, vos performances web sont probablement horribles!

Une fois que vous avez des données, tracez-les sur un graphique et effectuez une régression des moindres carrés dessus - extrapolez pour trouver le nombre de clients auxquels vous atteignez votre limite cible pour l'utilisation de la mémoire httpd. Un point de départ pour la cible mémoire serait le moindre de 80% de la mémoire physique / 80% de la taille du contenu.

(notez que si vous avez défini MinSpareServers sur une valeur très élevée, les résultats peuvent ne pas être précis)

#!/bin/bash

LOGFILE='/var/log/httpd/memusage'
PIDS = `ps -ef | grep httpd | grep -v grep | wc -l`
MEM = `free | grep 'buffers/cache'`
DAY = `date '%Y-%m-%d %H:%M:%S'`
echo ${DAY} ${PIDS} ${MEM} >>LOGFILE

Dans un monde idéal, vous mesureriez également le temps de réponse des URL dans le même fichier journal, mais cela devient beaucoup plus complexe.

— symcbean
source

Pour moi, les tampons / cache changent très peu, que ce soit en exécutant 11 clients ou lorsque le serveur a atteint 86 ou 151 clients (et que le serveur est tombé en panne). Qu'espérez-vous voir dans votre variable MEM? Je reçois deux chiffres, je me demande donc si Ubuntu 12.04 donne autre chose que ce à quoi vous vous attendiez.

— PeterB

Essayez de courir «gratuitement» et vous verrez ce que j'attends (2 chiffres). S'il est vrai qu'il y a peu de variation dans ces nombres avec différents nombres de processus, alors vous exécutez le serveur basé sur les événements ou votre paramètre maxspareservers est idiot. Si vous aviez publié un échantillon de la sortie et des parties pertinentes de votre httpd.conf, alors peut-être aurions-nous une meilleure image?

— symcbean

.... et "crash"? Quel accident?

— symcbean

Désolé, voir pastebin.com/aHZCagVn pour les paramètres httpd.conf et un exemple de sortie. Par «crash», je veux dire trop de clients, le serveur manque de mémoire et se bloque. Veuillez consulter pastebin.com/fnXzBfQL pour en savoir plus.

— PeterB

@PeterB, il semble plus probable que MySQLd soit à l'origine de ce problème. Lorsque le tueur OOM du noyau entre en action, il tue d'abord les pires contrevenants en fonction de la valeur de / proc / PID / oom_score_adj. Comme en témoigne votre sortie, mysqld est passé en premier. Vous devrez peut-être ajuster les paramètres dans my.cnf de manière plus appropriée pour s'adapter aux contraintes de votre machine virtuelle. Comme solution de contournement / temporaire /, pour voir si vous pouvez éviter les coups de pied du tueur OOM, essayez d'ajouter un fichier d'échange pour de la mémoire virtuelle supplémentaire; puis débarrassez-vous-en une fois que vous aurez identifié votre véritable problème.

— loopforever