Meilleure configuration sysctl.conf pour une charge élevée - serveur de streaming de contenu extrêmement occupé

Quelle est la meilleure configuration sysctl.conf pour un serveur de streaming de contenu très chargé et extrêmement occupé? Le serveur récupère le contenu des serveurs distants comme amazon, s3, etc., puis utilise php pour diffuser dynamiquement le contenu à l'utilisateur sans l'enregistrer sur le disque dur. php utilise CURL pour récupérer le fichier, puis utilise flush () pour le diffuser simultanément, donc peu de travail sur le disque dur ... uniquement le réseau et la bande passante.

Le serveur est un quad core xeon, avec une carte réseau full duplex 1 Gbit, 8 Go de RAM et 500 Go x 2 en RAID. L'utilisation de la mémoire du serveur et la charge du processeur sont assez faibles.

Nous utilisons debian lenny et lighttpd2 dessus (oui je sais que ce n'est pas encore sorti :-)) avec php 5.3.6 et php fastcgi avec spawn-fcgi bind sur 4 sockets unix différents avec 20 enfants chacun. Le nombre maximal de requêtes fcgi est de 20, avec le module mod_balancer en configuration lighttpd2 pour équilibrer les requêtes fastcgi entre ces 4 sockets en configuration SQF (file d'attente courte en premier).

Nos serveurs utilisent beaucoup de bande passante, c'est-à-dire que la connexion réseau est occupée tout le temps. Juste après 100 à 200 connexions parallèles, le serveur commence à ralentir et finit par ne plus répondre, commence à donner des erreurs de délai d'attente de connexion. Quand nous avions cpanel, nous n'avons jamais eu d'erreurs de timeout, donc ça ne peut pas être un problème de script. Il doit s'agir d'un problème de configuration réseau.

configuration de lighttpd2: processus de travail = 8, les requêtes de maintien en vie sont de 32, le délai d'inactivité de maintien en vie est de 10 secondes et les connexions maximales sont de 8192.

Notre contenu actuel de sysctl.conf est:

net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1

# Increase maximum amount of memory allocated to shm

kernel.shmmax = 1073741824

# This will increase the amount of memory available for socket input/output queues
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

# you shouldn't be using conntrack on a heavily loaded server anyway, but these are
# suitably high for our uses, insuring that if conntrack gets turned on, the box doesn't die
# net.ipv4.netfilter.ip_conntrack_max = 1048576
#  net.nf_conntrack_max = 1048576

# For Large File Hosting Servers
net.core.wmem_max = 1048576
net.ipv4.tcp_wmem = 4096 87380 524288

Le réglage des performances et l'identification des cols de bouteille comme celui-ci sont un problème difficile à résoudre et nécessitent souvent de nombreuses informations pour être diagnostiqués. La clé du processus est de passer par le processus qu'il utilise et de voir si vous pouvez trouver quelles ressources sont épuisées. Quand vous avez dit que le serveur ne répond pas au php, mais que le html sert toujours, c'est un point de données intéressant. Quelle est la différence entre la façon dont ceux-ci sont servis? Il peut s'agir de dépassements subtils de tampon réseau, ou il peut être plus basique que cela. Vous avez peut-être simplement épuisé la limite de 20 processus enfant fcgi enfant, et ils sont tous occupés à servir des données, tandis que de nouvelles demandes sont bloquées dans la file d'attente d'écoute (et expirent finalement) en attendant qu'un processus fcgi php soit lancé.

La véritable astuce lorsque vous essayez d'obtenir de la visibilité sur la boîte est de vous connecter à la boîte lorsque des problèmes surviennent et de commencer à collecter des informations.

Pour savoir combien de processus php sont en cours d'exécution, vous devriez pouvoir exécuter quelque chose comme ceci:

ps auxgmww | grep php

Et si vous souhaitez les compter plutôt que de les compter vous-même, vous pouvez faire quelque chose comme ceci:

ps auxgmww | grep php | wc -l

Retour à votre question d'origine sur le réglage des performances, avant de modifier syctl.conf, vous souhaiterez peut-être voir ce que votre serveur vous dit lorsque le problème se produit, vous pouvez le découvrir en procédant comme suit:

sysctl -a > sysctl.txt

Et puis affichez votre fichier texte - c'est un tas de données, mais avant de régler une valeur donnée, voyez si la sortie sysctl rapporte quoi que ce soit qu'il utilise actuellement pour ce réglage, et ce qu'il pourrait consommer. Un exemple est les fichiers ouverts, que vous pouvez voir un exemple de sortie ici:

fs.file-nr = 3456   0   102295

Cela nous indique que nous utilisons 3456 descripteurs de fichiers, mais notre limite est 102295, nous ne sommes donc pas du tout près de notre limite. Si le premier nombre avait été dans la plage 100000, cela vous indiquerait que vous manquez de descripteurs de fichiers et que c'est ce que vous devez régler.