Il faut que tu arrives à identifier plus finement la source du problème:
- commence par essayer d'arrêter les processus qui ne servent à rien, à couper X (si il est présent), etc…, afin de voir si par hasard une des ces applications est la cause des problèmes
- utilise "iotop" pour identifier les gros consommateurs d'I/O, qui sont des bons candidats aux ralentissements
- d'ailleurs, dans la commande "top", regarde la valeur du "wait" time. C'est le temps que le kernel passe à attendre le hardware. Si il est excessif, c'est qu'il y a un problème de disque, de réseau, etc… Qu'ils soient physiques ou virtuels
- utilise "strace" (perso, j'aime bien "strace -f -e open -p") afin d'identifier si un process s'amuse à beaucoup ouvrir/lire/écrire des fichiers. Récemment, sur un soft "métier", j'ai trouvé une application qui faisait 1200 ouvertures/fermetures par seconde d'un même fichier…
- coté réseau, utilise "tcpdump/wireshark" pour voir si tu n'as pas des trafics réseaux inhabituels. Notamment, si par exemple tu as du mal à trouver un serveur DNS (UDP port 53), que tu as du trafic ipv6 "mal configuré", etc… Si une appli passe son temps à attendre des informations du réseau, cela peut expliquer les ralentissements.
- pour ce qui est du fait que tu as une vds, regarde si ton hôte peut t'indiquer/comparer les consommations d'I/O entre les vds, voir si cette vds n'est pas moins prioritaire que les autres
Quand à la mémoire vive:
- Utilises en temps que root "sync ; echo 3 > /proc/sys/vm/drop_caches", ce qui va vider tous les caches (lecture/écriture) de la vds. Ainsi, en regardant l'évolution de "free", tu pourras voir si tu as des applis qui font beaucoup de lectures/écritures
- enfin, tu as plus de 500Mo de cache en écriture ( -/+ buffers/cache: 541468 3324092). Cela fait beaucoup. Tu dois avoir un process qui écrit beaucoup, "iotop" devrait donc t'aider à dénicher le coupable.
# Identification
Posté par Olivier (site web personnel) . En réponse au message mémoire ram occupé. Évalué à 8.
Il faut que tu arrives à identifier plus finement la source du problème:
- commence par essayer d'arrêter les processus qui ne servent à rien, à couper X (si il est présent), etc…, afin de voir si par hasard une des ces applications est la cause des problèmes
- utilise "iotop" pour identifier les gros consommateurs d'I/O, qui sont des bons candidats aux ralentissements
- d'ailleurs, dans la commande "top", regarde la valeur du "wait" time. C'est le temps que le kernel passe à attendre le hardware. Si il est excessif, c'est qu'il y a un problème de disque, de réseau, etc… Qu'ils soient physiques ou virtuels
- utilise "strace" (perso, j'aime bien "strace -f -e open -p") afin d'identifier si un process s'amuse à beaucoup ouvrir/lire/écrire des fichiers. Récemment, sur un soft "métier", j'ai trouvé une application qui faisait 1200 ouvertures/fermetures par seconde d'un même fichier…
- coté réseau, utilise "tcpdump/wireshark" pour voir si tu n'as pas des trafics réseaux inhabituels. Notamment, si par exemple tu as du mal à trouver un serveur DNS (UDP port 53), que tu as du trafic ipv6 "mal configuré", etc… Si une appli passe son temps à attendre des informations du réseau, cela peut expliquer les ralentissements.
- pour ce qui est du fait que tu as une vds, regarde si ton hôte peut t'indiquer/comparer les consommations d'I/O entre les vds, voir si cette vds n'est pas moins prioritaire que les autres
Quand à la mémoire vive:
- Utilises en temps que root "sync ; echo 3 > /proc/sys/vm/drop_caches", ce qui va vider tous les caches (lecture/écriture) de la vds. Ainsi, en regardant l'évolution de "free", tu pourras voir si tu as des applis qui font beaucoup de lectures/écritures
- enfin, tu as plus de 500Mo de cache en écriture ( -/+ buffers/cache: 541468 3324092). Cela fait beaucoup. Tu dois avoir un process qui écrit beaucoup, "iotop" devrait donc t'aider à dénicher le coupable.