Surcharge CPU sur Kimsufi 2G
moresk24
06/05/2015, 19h01
ça sèche ? o)
Bon j'ai un autre soucis.. mais je vais ouvrir un autre Topic... parce que là ça cause de tout o)
Merci en tout cas pour votre aide.
Moresk
moresk24
05/05/2015, 20h11
et bien...
en utilisant toujours webmin
création d'utilisateurs dans 'système' pour chacun des sites
puis des serveurs virtuels dans apache
et l'accès FTp est venu tout seul ma fois...
comment as-tu installé tes domaines ?
moresk24
05/05/2015, 19h37
j'enchaine : je me connecte en FTP sur le Kim, cela veut il dire qu'il y a automatiquement un serveur FTP qui tourne sur le serveur ?
moresk24
05/05/2015, 18h51
bon G trouvé (et avant de lire la réponse de BBR promis juré ;-) )
Dans Mysql -> Autorisations des utilisateurs, j'ai mis logiquement la permission LOCK TABLES à mon utilisateur 'mega3d', et zou le script ne sort plus d'erreur
;-)
le reste il te dit clairement que mega3d n'a pas le droit d'utiliser la base mega, faut que tu regardes de ce côté là
soit tu t'es trompé dans le nom du user soit dans celui de la base
moresk24
05/05/2015, 18h29

Envoyé par
BBR
ça doit se toucher le -pPassword
là, t'as choisi la question la plus facile avoue o)
ça doit se toucher le -pPassword
moresk24
05/05/2015, 18h07
entre voir de quoi ça parle, comprendre et apprendre (c'est à dire refaire)... y'a de la marge o)
Allez, je vous en pose une petite : mysqldump
deux sites
l'un à une sauvegarde auto depuis deux ans qui tourne sans problème
pour l'autre je recopie le fichier .sh du premier, je change ce qu'il faut (-u -p, nom de la base)
je lance.. mais :
mysqldump: Got error: 1044: Access denied for user 'mega3d'@'localhost' to database 'mega' when using LOCK TABLES
J'ai cherché sur le web pour pas vous tomber dessus de suite, mais pas trouvé..;
Vous en pensez quoi ?
question subsidiaire :
on peut se passer de mettre un espace entre -p et le password dans la commande mysqldump ?
du genre -> mysqldump -u mega3d -pMonMotDePass mega > mega3d_mysql_dump_$CUR_DATE.sql
Voilà pour cette fin d'aprem o)
Je crois que tu vas avoir appris en une semaine plus qu'en 3 ans
Ce n'est que le début
moresk24
05/05/2015, 09h50
En effet...
Merci o)

Envoyé par
moresk24
et à quoi correspondent ces fichiers là : other_vhosts_access.log ?
Va voir ton /etc/apache2/conf.d
T'as un fichier "other-vhosts-access-log." ?
La réponse se trouve dans ce fichier.
moresk24
05/05/2015, 09h30
et à quoi correspondent ces fichiers là : other_vhosts_access.log ?
Une fois que tu auras modifié tes fichiers, dans webmin, tu vas dans Système, Rotation de fichier journal et là tu cliques en bas sur Forcer la rotation du journal
Sur cette page tu peux aussi cliquer sur Modifier les options globales, ce sera peut-être plus simple pour toi et cela s'appliquera à tous les logs
les fichiers en .gz sont compressés et comme c'est du texte ils diminuent radicalement
vu la taille tu devrais changer la configuration des rotations
se déplacer dans le répertoire
Code:
cd /etc/logrotate.d
là tu vas voir tous les fichiers de configuration de rotation des logs
tu édites les fichiers et tu mets soit
daily à la place de
weekly ou tu peux aussi spécifier une taille maxi du fichier log, par exemple ici, c'est par défaut une fois par semaine mais si le fichier atteint 50M, la rotation se fait (le fichier log est compressé et un nouveau est ouvert)
Code:
/var/log/le_chemin_vers_les_logs_du_domaine_error_log {
rotate 52
weekly
size 50M
compress
postrotate
/usr/sbin/apache2ctl graceful ; sleep 5
endscript
sharedscripts
}
à adapter à ta configuration
et pour le fichier apache2
Code:
/var/log/apache2/*.log {
weekly
size 50M
missingok
rotate 52
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
/etc/init.d/apache2 reload > /dev/null
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}
tu as juste à modifier les lignes en gras
moresk24
05/05/2015, 07h46
dans etc/con.d/
mon fichier awstats contient :
*/10 * * * * www-data [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh
# Generate static reports:
#10 03 * * * www-data [ -x /usr/share/awstats/tools/buildstatic.sh ] && /usr/share/awstats/tools/buildstatic.sh
moresk24
05/05/2015, 07h43
Dans var/log/apache2 je vois par exemple :
other_vhosts_access.log qui pèse 225MB -> ce matin à 7:15
other_vhosts_access.log.1 qui pèse 713 MB 6> 3 may
sinon les autres other_vhosts_access.log.10.gz par exemple ne pèse que 23MB
les autres fichiers du même nom pèse environ 20MB-24MB
les acces.log -> 101 kb et access.log.1 -> 344 kb
et les autres access.XX.log.gz -> moins de 20 kb
Lorsqu'on "kill" un processus, le fait de redémarrer le serveur relancera t il se processus ?
car depuis que j'ai kill hier celui concernant awstats, j'ai fait la Maj de debian 6 (avec anxiété mais succès lol) et rebooté le serveur mais ma page d'accès aux stats me renvoie désormais une erreur 404 (The requested URL / was not found on this server.)
Moresk
il n'a toujours pas fini à 7h du matin par exemple ?
beh alors c'est que ton serveur est trop limite en cpu par rapport aux logs qu'il y a ... ce n'est pas normal que çà prenne autant de temps.
Dans ton logrotate, apache est configuré comment ?
more /etc/logrotate.d/apache
si les logs sont trop gros, remplace
weekly par daily
et
si tu veux par exemple garder les logs apache des 365 derniers jours mets
rotate 365
tu as redémarré le serveur après les mises à jour ?si non, çà peut être utile de le faire ....
tape dans la console SSH
reboot
moresk24
04/05/2015, 20h48
le soucis c'est qu'il calcule sans s'arrêter, prenant au mini 85% du CPU...
heu, c'est la même chose...
# = ligne commentée donc non lu/appliquer
est-ce grave si ton CPU fait les calculs pour awstats ? ce n'est pas le pub recherché d'avoir des statistiques ?
sinon, tu peux le supprimer ici : /etc/cron.d/awstats mais du coup awstats ne marchera plus ...
nicobilaine
04/05/2015, 20h01

Envoyé par
moresk24
ça serait il si simple de passer d'une version à une autre ?
En théorie et avec Debian et ses dérivés : oui. Par contre, si il y a des modifications dans les fichiers de configuration ou si les paquets changent radicalement, il faut répondre à une question (garder l'ancien fichier de config, prendre le nouveau, comparer les deux, ...). Et comme on est connecté en SSH, il vaut mieux lancer la commande "screen" avant (ça permet, de ce que j'ai compris, de lancer une session virtuelle et de pouvoir la reprendre) car en cas de coupure de la liaison, il faut couper la mise à jour en cours et la relancer en espérant qu'il n'y ai pas de soucis.
Dans tous les cas, il faut une bonne sauvegarde.
quand tu mets un # devant une ligne tu la "commentes" c'est à dire que tu empêches sa prise en compte (c'est comme si elle n'existait pas)
edit : zut je n'avais pas vu les commentaires au-dessus
moresk24
04/05/2015, 17h25

Envoyé par
nicobilaine
Les commandes apt-* ne mettent pas à jour la version de debian (6, 7, 8) mais juste les paquets de la distribution actuelle. Pour changer de version, il faut modifier le fichier "/etc/apt/sources.list" avec le nom de la version suivante (donc "wheezy" au lieu de "squeeze") puis refaire les mises à jour. Bien entendu, il faut faire les sauvegardes avant au cas où.
ça serait il si simple de passer d'une version à une autre ?

Envoyé par
nicobilaine
Est-ce que #mysqldump est dans un script? Si oui, le # au début de l'instruction la met en commentaire, elle n'est donc pas exécutée.
En effet c'est une ligne d'un script
Merci pour la réponse
nicobilaine
04/05/2015, 17h09
Les commandes apt-* ne mettent pas à jour la version de debian (6, 7, 8) mais juste les paquets de la distribution actuelle. Pour changer de version, il faut modifier le fichier "/etc/apt/sources.list" avec le nom de la version suivante (donc "wheezy" au lieu de "squeeze") puis refaire les mises à jour. Bien entendu, il faut faire les sauvegardes avant au cas où.
Est-ce que #mysqldump est dans un script? Si oui, le # au début de l'instruction la met en commentaire, elle n'est donc pas exécutée.
moresk24
04/05/2015, 16h42
Une p'tite question en passant :
c koi la différence entre #mysqldump et mysqldump ?
Mais que ça ne vous détourne pas du problème de base : surcharge du cpu dû à un script d'awstats ;-)
apt-get install htop
puis pour le lancer : htop
c'est comme top mais en mieux
moresk24
04/05/2015, 14h00
bon, la Maj s'est bien déroulée, le serveur est toujours là en : (Debian Linux 6.0.10)
moresk24
04/05/2015, 13h18
Merci BBR, Buddy et Nowwhat pour ces informations
Nowwhat :
Ma connexion sat me permet en effet des DL et UpL en illimité de 23:00 à 7:00
J'ai fait les sauvegardes dont tu parles (/etc, /home, /root, /boot et tout le /etc depuis le travail. Donc ça c ok
les sites sont 'rangés' dans le répertoire /home/ et non dans le /var/www/ -> pas bien ?
Je n'ai pas de serveur mail d'installé sur le kim. C'était un projet, mais ne me sentant pas de taille, j'ai abandonné
je vais donc cette aprem me lancer dans la Maj de Debian 6, avant de me pencher sérieusement sur le passage du serveur vers Debian 7 (Wheezy, la dernière verion = 7.8).
Pour en revenir à mon soucis de base : surcharge du CPU :
je vous avais je crois raconté qu'une sauvegarde se faisait à l'heure ou cette surcharge semblait apparaitre.
j'ai donc désactivé cette tâche cron, mais... la surcharge à repris vers 00:20
Sur les conseil d'un gars comme vous : commande top pour voir la liste des processus en route
repérage d'un processus qui prend 86% du CPU
commande 'ps aux' pour en connaitre le PID
puis un 'kill'
Le processus en cause semble lancé par l'user www-data -> statistiques du site principal hébergé sur ce serveur (par AWStats)
C'est donc la semble t il que se situe le soucis de surcharge du CPU
Voilà où j'en suis.
Moresk
Sans le "-y" :

Envoyé par
moresk24
apt-get update && apt-get upgrade
Ceci est comparable avec la mise à jour de Windows:
La liste des programmes à mettre à jour jour est chargé (apt-get update) - ce qui est une opération sans risque.
La liste des programmes à mettre à jour est affiché (apt-get upgrade).
A toi de confirmer avec Y + entrée.
Fait comme ton OS Windows: accepte ces mise à jour de sécurité sans réfléchir. Certains services/programmes seront redémarré, et ça se passe bien dans 99,999 % des cas.
Mais attention: cette opération te ramène à la dernière version de Debian 6 (Squeeze). cette version n'est plus supporté par 'Debian' depuis des lustres.
La date de fin du support de Debian 7 (Wheezy) est aussi connu: "Debian 8" est sortie, ça fait plus d'une semaine.
Prépare-toi pour passer ton serveur vers Debian 7 (Wheezy, la dernière verion = 7.8), tu sera tranquille pour un bout de temps.
AVANT de procéder, il suffit de lire quelques des milliers des procédures disponible sur le net.
Que tu te fasse un idée ce qu'il faut faire.
Je te conseille de copier un max de données présent sur ton serveur vers ton PC.
Le répertoire et toutes les sous-répertoires:
/etc
/home
/root
/boot
Le répertoire /var/ est spécial. Je te conseille de copier
/var/www/* (surtout - normalement, tes sites sont là)
/var/log/*
et tout autre répertoire dans /var/ qui t’intéresse.
Ta connexion (satellite) ne te permet de transférer des données illimités entre minuit et 07h00 ?
edit: bonus:
http://journaldunadminlinux.fr/aptic...-jours-debian/
Un petit outil très sympa.
Après install, edit /etc/apticron/apticron.conf pour que tu change EMAIL="....." pour ton adresse mail, exempel: EMAIL="ton-adressemail.tld".
Condition: je présume que t'as un serveur mail sur ton dédié.
salut,
sous debian apt-get update tout seul n'update rien ...
Il faut faire
apt-get update && apt-get upgrade -y
tu peux si tu veux reboot ton serveur après. (commande reboot). Il me semble que c'était recommandé pour corriger les failles de sécurité de fin 2014. (shellshock + les failles SSL)
apt-get update && apt-get upgrade -y && reboot
c'est le serveur qui se connecte, pas toi !
pour les sauvegardes tu as des pistes par ici :
http://www.how-to.ovh/viewforum.php?f=9
une sauvegarde sur le serveur ne sert à rien si ton disque rend l'âme.
moresk24
03/05/2015, 21h00
Merci BBR,
dernière question avant que je ne me lance : est ce ma connexion internet qui est utilisée pour cette MAJ du serveur ?
A priori non, mais Je demande cela car je suis sur un Internet par satellite, avec donc un forfait limité en DL et UpL
La Maj est à faire une fois par semaine dis tu.... et une fois par '3 ans' ne suffit donc pas ?? o) Donc j'ai du retard, je vais le rattraper
Je me contenterai de la commande 'apt-get update' pour la première fois
La sauvegarde du site principale se fait sur le serveur, et je télécharge de temps en temps cette sauvegarde
ça serait quoi la solution la plus 'sérieuse' ?
J'ose pas... apt-get update... o)
moresk24
03/05/2015, 20h55
Merci BBR,
dernière question avant que je ne me lance : est ce ma connexion internet qui est utilisée pour cette MAJ du serveur ?
A priori non, mais Je demande cela car je suis sur un Internet par satellite, avec donc un forfait limité en DL et UpL
La Maj est à faire une fois par semaine dis tu.... et une fois pas '3 ans' ne suffit donc pas ?? o) Donc j'ai du retard, je vais le rattraper
Je me contenterai de la commande 'apt-get update' pour la première fois
La sauvegarde du site principale se fait sur le serveur, et je télécharge de temps en temps cette sauvegarde
ça serait quoi la solution la plus 'sérieuse' ?
J'ose pas... apt-get update... o)
Tu laisses faire, ça va se connecter sur le site de Debian et récupérer les mises à jour et les installer, rien d'autre.
C'est à faire au moins une fois par semaine.
As-tu aussi un système de sauvegarde externe au serveur ? (tu parles de sauvegardes mais elles se font où ? Si c'est sur le serveur elles ne servent à rien)
Perso je fais toujours
apt-get update && apt-get upgrade -y
afin que les paquets soient aussi upgradés si besoin mais sur une distribution pas mise à jour depuis des lustres, je ne sais pas si c'est judicieux
moresk24
03/05/2015, 15h16
Allez soyons fous !!
Mais...
Une fois la commande 'apt-get update' lancée, y aura t il d'autre chose à faire ?
Dois-je par exemple arrêter apache ou autre avant de lancer cette commande ?
En résumer : à quoi dois je m'attendre lorsque j'aurais appuyé sur 'return' ?
pascaltits
03/05/2015, 14h35
là ton os et peut être un peu vieux et surtout pas à jour du tout.
BBR à raison, ton serveur doit être bourré de failles qui ont peut être compromis ton serveur ...
Une réinstallation complète serai plus sure, et surtout retenir la leçon :
apt-get update de façon régulière.
Debian 6 s'arrête à la 6.0.10
la commande est simple, en ssh tu tapes cela et tout se mettra à jour :
apt-get update
et OUI il faut toujours faire les mises à jour car ton serveur doit être bourré de failles
et Debian en est à la Version 8, sans aller jusqu'à la 8, passer en Debian 7.8 serait déjà bien
moresk24
03/05/2015, 13h26
et pour la commande dmesg :
quelque chose en particulier ?
Parce que je ne peux pas l'ensemble du texte (trop long)
moresk24
03/05/2015, 13h21
Warning - Your system is actually running Debian Linux version 6.0.5.
Webmin version 1.740 is now available, but you are running version 1.610.
Je dois mettre à jour Debian ?
La chose se fera t elle simplement ?
pascaltits
03/05/2015, 13h07
En observant l'utilisation du CPU je m'aperçois que depuis le 23 avril les pic à 100 (% ) sont très nombreux.
A quel fréquence ? est-ce régulier ? quel heure ?
J'ai redémarré le serveur (qui a eu du mal d'ailleurs),
que donne :
dmesg
Pascal
ce serveur est-il à jour ?
moresk24
03/05/2015, 11h42

Envoyé par
janus57
faut regarder les logs et éventuellement faire les tests hardware car le serveur pourrait ralentir à cause d'un I/O Wait important du a un HDD défaillant ou a un site devenu trop gros pour votre système de backup qui a besoin d'optimisation.
Quels logs dois je regarder ? parce que des fichiers log j'en vois partout o)
La sauvegarde quotidienne pèse 500 mega (+ 2 mega pour la sauvegarde de la BDD)

Envoyé par
janus57
Vous n'avez pas des graphs de monitoring (autre que le manager bien sûr) ?
Des graphs... que je pourrais trouver où sur le serveur ?
A noter que n'étant pas professionnel de la profession, j'utilise Webmin...
Merci de votre aide Janus
Bonjour,
faut regarder les logs et éventuellement faire les tests hardware car le serveur pourrait ralentir à cause d'un I/O Wait important du a un HDD défaillant ou a un site devenu trop gros pour votre système de backup qui a besoin d'optimisation.
Vous n'avez pas des graphs de monitoring (autre que le manager bien sûr) ?
Cordialement, janus57
moresk24
03/05/2015, 10h06
Serveur :
Système (OS)
Debian 6.0 LTS ("Squeeze") (oldoldstable)
Boot
hd (Boot from hard drive (no netboot))
Nom commercial
Kimsufi 2G
Bonjour,
En observant l'utilisation du CPU je m'aperçois que depuis le 23 avril les pic à 100 (% ) sont très nombreux. J'ai redémarré le serveur (qui a eu du mal d'ailleurs), l'utilisation du cpu est alors retombée à ce qui était la norme précédemment (pas plus haut que 25), mais de nouveau, 24 heures plus tard,les pics à 100 sont redevenus très fréquents.
A noter qu'une sauvegarde du site hébergé sur ce serveur se lance vers minuit trente (tâche cron), et il me semble que le soucis de surcharge du CPU s'est redéclenché à cette heure là.
Ce site tourne depuis 3 ans, et la sauvegarde depuis ce temps n'a jamais posé de soucis....
Pouvez vous m'apporter une petite aide pour que je sache comment résoudre ce problème qui occasionne un ralentissement net sur le site principal que j'héberge sur ce serveur..
Merci pour votre aide.
Stève Cuvelier