2014-04-27 2 views
2

Nous utilisons CouchDB v1.5.0 sur AWS et cela fonctionne très bien. Récemment, AWS est sorti avec de nouveaux prix pour leurs nouvelles instances m3, donc nous avons changé notre instance CouchDB pour utiliser m3.large. Nous avons une base de données relativement petite avec < 10GB de données. Nos métriques d'état stable sont des charges système de 0,2 et des utilisations de la mémoire de 5% environ. Cependant, nous avons remarqué que toutes les quelques heures (3-4 fois par jour) nous obtenons un énorme pic qui planifie notre charge à 1,5 ou presque et l'utilisation de la mémoire à près de 100%.Pointe de charge CouchDB (même avec peu de circulation)?

Nous n'exécutons aucun cronjobs impliquant la base de données et notre flux de trafic à peu près le même au cours de la journée. Nous effectuons une réplication continue d'une base de données sur la côte ouest à une autre sur la côte est.

Cela m'a bloqué pour un peu - des idées?

+0

C'est un bon sujet à discuter sur [liste de diffusion de l'utilisateur CouchDB] (http://couchdb.apache.org/#user-mailing-list) car il n'est pas simple de donner une réponse sans beaucoup de détails: les graphiques pour les statistiques du système couchdb et du système, les logs liés au pic, la configuration du système et du couchdb et ainsi de suite. Voulez-vous l'exécuter ici? Vous êtes libre de poster la solution que nous avons trouvée pour votre problème. – Kxepal

+0

c'est une bonne idée - il suffit d'envoyer la liste des utilisateurs à [email protected] – martyhu

Répondre

0

Je voulais juste faire un suivi sur cette question au cas où cela aiderait quelqu'un.

Même si je n'ai pas trouvé de réponse directe à ma question de pic de charge, j'ai découvert un autre bug en inspectant les logs que j'étais capable de résoudre. Dans mon cas, l'exécution de «sudo service couchdb stop» n'arrêtait pas vraiment couchdb. En plus de cela, toutes les deux secondes, un nouveau processus de canapé essaierait et apparaîtrait seulement pour être bloqué par le processus couchdb existant. En fin de compte, la suppression de l'indicateur Respawn /etc/init.d/couchdb a corrigé cette erreur.

Questions connexes