2015-08-19 1 views
0

Lors du test de Monetdb sous Linux, je peux voir beaucoup d'activité d'écriture E/S. L'ensemble de données est de 2 Go (30 millions de lignes) et le système a 120Go RAMMonetDB requête parallèle haute activité d'écriture IO

La requête:

select sum(hits) from (select "hour","minute","second", server, count(*) as hits from iislogs group by server, "hour","minute","second") as xxx; 

Je dirige une seule requête, il prend ~ 400 ms pour scanner 30 lignes Mil, mais si je cours même requête 10 fois en parallèle chaque prend 30 s! Les 48 CPU sont à 15% et je peux voir beaucoup d'écritures sur disque, pas d'activité de swap. Je cherche à peaufiner une sorte de réglage ou de limitation sans aucune chance.

Une idée sur pourquoi?

MISE À JOUR:

J'ai désactivé la journalisation et écrire actif a réduit mais ayant encore un peu et aucune amélioration.

Répondre

1

Vous pouvez essayer d'autoriser plus de pages sales dans le cache de pages. Nous avons eu un certain succès avec les paramètres de mémoire virtuelle suivants:

sudo sysctl -w vm.swappiness=0 
sudo sysctl -w vm.dirty_expire_centisecs=6000000 
sudo sysctl -w vm.dirty_background_ratio=90 
sudo sysctl -w vm.dirty_writeback_centisecs=6000000 
sudo sysctl -w vm.dirty_ratio=90 
+0

Merci, dois-je redémarrer le service ou quelque chose d'autre après? * vm.dirty_background_ratio = 90 * N'a pas été présent mais je l'ai quand même défini. Malheureusement aucune amélioration du tout en ce moment, des tonnes de ressources inutilisées là: ( – GBrian

+0

Redémarrer MonetDB, oui. Pas d'amélioration non plus? –

+0

Pas du tout :(vérifier ce lien http://tinypic.com/r/mtl547/8 requête unique est ~ 400ms, la multiquery est ~ 4s en cours d'exécution 10 requêtes parallèles, j'ai essayé désespérément un entonnoir/multiplexeur pas d'amélioration.Mettez-moi savoir quels détails peuvent vous aider Ceci est le script que j'utilise (peut-être l'erreur est là): https : //docs.google.com/document/d/1G0aMtvxysMYXlH2E8ytOTt-kupAbnLfP5YsWgwcnj7c/edit? usp = sharing – GBrian