Aller au contenu

mtcocktail

Webmaster Régulier
  • Compteur de contenus

    64
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par mtcocktail

  1. Bah en fait tu peux pas demander à un hebergeur type discounter de te prodiguer des conseils d'infogerances. Ils sont là pour fournir une infrastructure réseau. Après l'optimisation des serveurs il s'en foute un peu je pense. Donc soit tu prend un prestataire externe pour des missions ponctuels genre dan, moi ou d'autre sur ce forum. Qui peuvent faire des presta de configuration ou d'infogérance. Sinon tu vas chez un hebergeur qui te fera également l'infogerance mais là tu sera chez un hebergeur Pro sur des tarifs beaucoup plus important que ceux d'Amen. Sinon la migration d'un plesk pas de soucis, l'agent de migration de plesk fonctionne très bien.
  2. Un firewall mal configuré, une lenteur du réseau Amen, là les causes commence à être nombreuse si tu n'a pas de message ou d'erreur précise à nous communiquer . Heu après la diminution des fichier de log je te conseil un bon vieux restart d'apache aussi. Car apache à tendance à laisser ces fils dans la swap et comme dis Dan , swap y'a pas bon
  3. Bof, y'a peu de Tentatives échouées 1,42% et de Arrêts prématurés 0,08%. Je rajouterais dans le fichier /etc/my.cnf deux lignes : log-slow-queries = /var/log/mysqlslow.log long_query_time=3 Qui vont permettre de loguer toute les requête qui mette plus de 3 secondes à s'executer. Ensuite soit les requêtes sont longue car complexe et mal optimisé. Soit tu peux essayer de donner un peu plus de memoire à mysql en augmentant par exemple : key_buffer_size = 32M sort_buffer = 15M read_buffer_size = 512K Et aussi activer la fonction de cache de mysql ça fait toujours du bien . Par exemple 45 Meg de cache sur des requête dont le résultat est inférieur à 50K query_cache_size = 45M query_cache_type = 1 # 0 off, 1 On, 2 Demand query_cache_limit = 50K
  4. Rien de spécial ce sont des message classique lors d'une ouverture de connexion sur le smtp. Aprés le logrotate avec un fichier error_log de quelque Ko est-ce que ça remarche mieux ?
  5. Essaye de faire tourner les log et voir si tu obtient de nouveau un comportement normal : # logrotate -f /etc/logrotate.conf Et effectivement 250Mo d'error si le fichier a juste une semaine ça fais beaucoup d'erreur
  6. Ouep, ou alors t'a des fichier de log Apache qui ne tourne pas bien et qui font plus de 300 Mo Aprés tous depend de ton application et du code. Si tu as une grosse base de données avec peu ou pas d'index par exemple, ca peux aller vite pour saturer un serveur.
  7. Pendant une forte charge il nous faudrait le résultat de la commande top. Ensuite je pense que ton Maxclient est peut-être un peu faible. Essaye d'activer la page de status d'apache. Ce sont des ligne en commentaire dans le fichier httpd.conf du style : <Location /server-status> Event Handler status order allow,deny deny from all </Location> Decommente aussi la ligne : Extended-Status On Il faut bien sur modifier le allow from pour autoriser ton adresse, et enssuite te rendre sur l'url http://www.tondomaine.com/server-status/ Si tu peux nous donner le résultat pendant une forte charge..
  8. tu n'as pas la délégation dns de la zone nsxxxx.ovh.net. C'est simplement un enregistrement A du nom de ton serveur. Tu ne peux donc pas déclarer de sous domaine sur cet enregistrement.
  9. Le warning est juste sur le client mysql pas sur le serveur. tu peux enlever sans aucun soucis de data un libmysqlclient 4.0
  10. Si tous fonctionne en mettant l'ip effectivement c'est que la propagation DNS du domaine ne doit pas encore être bonne. Tu peux vérifier la configuration DNS de ton domaine avec un outil du type DNSREPORT de http://www.dnsstuff.com/ par exemple. Tu verra alors si le MX du domaine pointe bien sur le serveur, si c'est le cas les mail vont commencer à arriver sur le serveur. Dans tous les cas après changement DNS d'un domaine la propagation est en generale de 24h comme le précise DAN
  11. Cool Mais encore une petite question Comme c'est une base de redhat 7.2 j'ai vu également sur le ftp d'ovh les rpm d'origine genre ucd-snmp ( plus ancien que le 5.4 de net-snmp je te l'accorde ). Est-ce qu'il vaut mieux rester sur ses rpm de redhat7.2 ou alors partir forcement sur des compil à la mano car la release d'ovh est vraiment modifié. Mais dans ce dernier cas j'immagine qu'on est pas vraiment sûr de la stabilité de l'install ?
  12. Merci Dan mais je demande bien pour l'install de snmp mais pas de smtp
  13. Bonjour, Question rapide est-ce qu'il ya des retour d'experience d'installation de snmpd sur un serveur OVH sous release 1 ?
×
×
  • Créer...