2017-01-16 2 views
2

Nous avons hébergé notre site wordpress sur aws ec2 avec autoscaling et EFS.Mais tout d'un coup, le PermittedThroughput est devenu près de zéro octet et BurstCreditBalance devenait de moins en moins au jour le jour (de 2 To à quelques Mbs!). La taille d'EFS était seulement autour de 2GB!. Nous sommes confrontés à cette question une deuxième fois. Je voudrais savoir s'il y a quelqu'un qui a une expérience similaire ou une suggestion sur cette situation. Planification pour passer de EFS à NFS ou glusterfs les jours à venir.Dégradation des performances d'AWS EFS

cloudwatch graphp

enter image description here

+1

Cela n'a aucun sens de passer à votre propre NFS ou glusterfs qui utilisent EBS. Comme le souligne @ Michael Astuce sur "stocker plus de fichiers", vous pouvez simplement mettre quelques fichiers fictifs énormes dans le débit de votre gain de stockage EFS. – mootmoot

Répondre

5

Throughput sur Amazon EFS échelles en tant que système de fichiers se développe.

...

La capacité d'éclatement (tant en termes de durée et le taux de rupture) d'un système de fichiers est directement lié à sa taille. Les systèmes de fichiers plus volumineux peuvent éclater à des taux plus élevés pendant de plus longues périodes. Par conséquent, si votre application doit éclater davantage (c'est-à-dire si vous trouvez que votre système de fichiers est à court de crédits en rafale), vous devez augmenter la taille de votre système de fichiers.

Remarque

Il n'y a pas provisioning avec Amazon EFS, pour ainsi rendre votre système de fichiers plus grand, vous devez ajouter des données.

http://docs.aws.amazon.com/efs/latest/ug/performance.html

Vous avez dit que votre système de fichiers est que stocker des données 2 Gio. C'est le problème: il est contre-intuitif à première vue, mais EFS obtient effectivement plus vite comme il obtient plus grand ... et le contraire est également vrai. Les petits systèmes de fichiers accumulent des crédits en rafale seulement à raison de 50 KiB/sec par seconde par GiB de données stockées.

Ainsi, pour un système de fichiers Gio 2, vous allez épuiser vos crédits en transférant une très petite quantité de données par jour:

60 sec/minute × 
60 min/hour × 
24 hr/day × 
0.05 MiB/s per GiB stored × 
2 GiB stored = 8,640 MiB/day 

donc environ 8,6 Gio par jour est tout le transfert de données ce système de fichiers peut supporter. Cela semble étrange jusqu'à ce que vous vous souveniez que vous ne payez que 0,60 $ par mois.

Vous pouvez améliorer linéairement les performances en stockant simplement plus de données. La taille du système de fichiers utilisée pour le calcul est mise à jour une fois par heure, donc si vous suivez cette route, vous devriez voir une légère augmentation dans quelques heures.

La raison pour laquelle cela a bien fonctionné jusqu'à maintenant est que chaque nouveau système de fichiers est livré avec un solde créditeur initial équivalent à 2,1 TiB. Ceci est principalement destiné à permettre au système de fichiers d'être rapide lors du chargement initial des données, mais dans un environnement de stockage total bas tel que celui que vous décrivez, il durera des jours ou des semaines et vous apparaîtra soudainement (apparemment) finalement voir le système se stabiliser à son comportement de base correct. Essentiellement, vous payez pour les paramètres de deux paramètres interconnectés - la capacité de stockage totale et le débit de base - aucun de ces paramètres n'étant configuré. Si vous voulez plus de stockage, il suffit de stocker plus de fichiers ... et si vous voulez plus de débit, juste ... stocker plus de fichiers.