Pb avec les requêtes Apache2 au delà de 256 (resolu!)

Support Debian
#1

Je souhaiterais avoir un petit renseignement… je suis en train de travailler sur un serveur Apache, sur Debian. Or j’ai un problème qui devrait vous paraitre intéressant… La configuration, telle que je l’ai constaté, au niveau fichier httpd.conf contient les lignes suivantes :

prefork MPM

StartServers: number of server processes to start

MinSpareServers: minimum number of server processes which are kept spare

MaxSpareServers: maximum number of server processes which are kept spare

ServerLimit: maximum value for MaxClients for the lifetime of the server

MaxClients: maximum number of server processes allowed to start

MaxRequestsPerChild: maximum number of requests a server process serves

StartServers 8 MinSpareServers 25 MaxSpareServers 50 ServerLimit 600 MaxClients 220 MaxRequestsPerChild 2000

worker MPM

StartServers: initial number of server processes to start

MaxClients: maximum number of simultaneous client connections

MinSpareThreads: minimum number of worker threads which are kept spare

MaxSpareThreads: maximum number of worker threads which are kept spare

ThreadsPerChild: constant number of worker threads in each server process

MaxRequestsPerChild: maximum number of requests a server process serves

StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0

Je constate déjà que la personne qui a configuré le serveur a installé le prefork MPM et le Worker MPM. Or l’un est plus optimisé pour apache1.3 (ou 1.2 je ne sais jamais…). Je me demandais donc, à ce niveau, si cela pouvait handicaper la configuration.

D’autres part, nous avons constaté des erreurs dès lors que nous avions plus de 256 connexions simultanées… j’aurais compris si les erreurs s’étaient produites au delà de 220 (puisque telle est la config, ici), mais là? Je ne vois pas. Il ne semble pas non plus y avoir de BDD associées (j’apporte cette précision car mysql peut être paramétrée selon le même principe, à savoir de ne pas accépter un nombre excedent 256 connexions simultanées - ce qui est le paramétrage par défaut, du reste).

La version du serveur est Server Apache/2.0.52.

Quelqu’un a une idée? Ca m’arrangerait, c’est pour mon taff…

Merci d’avance… :=)

#2

Je rajoute juste un élèment que je sais utile :

#free
total used free shared buffers cached
Mem: 2074760 2040928 33832 0 90948 1648864
-/+ buffers/cache: 301116 1773644
Swap: 2040212 8388 2031824

#3

bon pour apache je ne sais pas. sinon sa swaps le systeme peux donc mettre du temps a répondre d’ou les 256 a la place des 220

peso je dirai que c’est la qu’il faut regarder.http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/explicitmatches.html#hashlimitmatch

#4

Super… C’est effectivement une hypothèse valable - du moins, il me semble. Je crois qu’un de mes collègues à été confronté à une situation très similaire et un résultat comparable… je n’y avais pas pensé. Très bien vu.

Merci!

Je vais pousser un peu le truc, histoire de voir si je peux confirmer.

Amicalement,

#5

“Ça swappe” ? Tu plaisantes ?

Sur les 2 Gio de RAM, les processus n’occupent que 300 Mio. Le reste est majoritairement occupé par du cache disque qui est libérable en cas de besoin. Il n’y a quasiment pas de RAM non occupée, ce qui indique qu’il n’y a pas une grosse quantité de mémoire qui aurait été allouée puis libérée récemment. Quant au swap, il n’est occupé qu’à hauteur de 8 Mio, c’est-à-dire une misère en comparaison de la taille de la RAM. Pour rappel, il n’est pas anormal que le noyau pousse des pages mémoire dans le swap alors qu’il y a plein de RAM disponible : il fait ça avec des pages inactives afin de faire de la place pour le cache disque, c’est plus efficace.

#6

[quote=“PascalHambourg”]“Ça swappe” ? Tu plaisantes ?

Sur les 2 Gio de RAM, les processus n’occupent que 300 Mio. Le reste est majoritairement occupé par du cache disque qui est libérable en cas de besoin. Il n’y a quasiment pas de RAM non occupée, ce qui indique qu’il n’y a pas une grosse quantité de mémoire qui aurait été allouée puis libérée récemment. Quant au swap, il n’est occupé qu’à hauteur de 8 Mio, c’est-à-dire une misère en comparaison de la taille de la RAM. Pour rappel, il n’est pas anormal que le noyau pousse des pages mémoire dans le swap alors qu’il y a plein de RAM disponible : il fait ça avec des pages inactives afin de faire de la place pour le cache disque, c’est plus efficace.[/quote]

soyons franc, j’ai rien compris. pour moi 8 Mo sur le disque c est inutile si la mémoire est disponible, car tout ce qui est en mémoire est plus rapide. aux niveau hardware c’est incontestable.

ben un petit coups de swpoff -a && swapon -a :slightly_smiling: et sa roule

#7

Je vois ça… :frowning:

Non, ce qui est inutile, c’est 8 Mo de données ou de code qui dorment en RAM alors qu’ils ne sont jamais utilisés -> hop ! en swap, ça libère de la RAM, plus rapide que les disques, pour y mettre des choses plus utiles comme du cache de fichiers qui, eux, sont accédés. Swapper les pages inactives serait inutile si la RAM était suffisante pour contenir non seulement les processus mais aussi toutes les données des disques auxquelles on accède plus d’une fois entre le démarrage et l’arrêt, ce qui n’est généralement pas le cas. Les pages qui dorment dans le swap ne ralentissent pas le système, au contraire. Fais confiance au système pour décider à quoi il est le plus utile d’affecter la RAM.

Surtout pas ! Il sera bien temps de sortir les pages du swap lorsque le processus auquel elles appartiennent en aura besoin - si jamais il en a besoin. En attendant, autant libérer la RAM pour des choses plus utiles que du contenu dormant.

C’est plus clair, là ?

#8

Les 220 donne le chiffre maximal de clients servis en même temps. Une connexion laisse un certain temps d’attente avant de déclarer la connexion impossible, je pense que le chiffre 256 signifie 220 clients servis et 46 en attente et que c’est plutôt en gros 250 que pile poil 256 (mais c’est une opinion personnelle). Beaucoup de requêtes sont servies très rapidement donc ça ne me parait pas impossible comme explication. Monte le niveau maximum de client et regarde si la saturation grimpe en proportion, si oui, l’explication est valable.

#9

Wow, je vois que j’ai soulevé un lièvre… merci à tous pour vos réponses… C’est bien utile, tout ça. En fait, apparemment, tout le monde a un peu raison, dans l’affaire. De plus, le client semble avoir trouvé la solution : un pb de bases de données aurait engendré un accroissement du nombre de connexions… (je ne vois pas pourquoi… ou alors pour obtenir sa page, il fallait deux tentatives de connexions, ou plus? je n’ai pas accès à sa base, donc…).

Je laisse la page ouverte, pour le moment : si quelqu’un veut rajouter quelque chose… nop.

Salutation, Fran.B… Tjs là pour me filer un couup de main. Tes explications, toujours fort claires et intéressantes, restent les bienvenues. C’est cool.

Merci à tous pour vos suggestions. :slightly_smiling:

#10

Done

#11

Pour debuger, tu peux simuler une charge sur un serveur apache avec l’utilitaire apache ab (pour Apache Benchmark). il est fourni en standard dans le paquet apache server.

SUMMARY ab is a tool for benchmarking your Apache Hypertext Transfer Protocol (HTTP) server. It is designed to give you an impression of how your current Apache installation performs. This especially shows you how many requests per second your Apache installation is capable of serv‐ ing.

#12

done