우리는 자동 확장 및 EFS와 함께 aws ec2에서 우리의 WordPress 사이트를 호스팅했습니다. 그러나 갑자기 PermittedThroughput이 0 바이트에 가까워지고 BurstCreditBalance가 날마다 줄어들고 있습니다 (2TB에서 몇 Mb!). EFS 크기는 약 2GB 밖에되지 않았습니다!. 우리는이 문제에 두 번째로 직면 해 있습니다. 나는이 상황에 대한 비슷한 경험이나 제안이있는 사람이 누구인지 알고 싶습니다. 앞으로 EFS에서 NFS 또는 glusterfs로 옮길 계획입니다. 파일 시스템이 성장함에 따라 
성능 저하 AWS EFS
당신은 당신의 파일 시스템은 데이터의 2 지브를 저장하는 것을 언급했다. 그것이 문제입니다. 처음에는 반 직관이지만 EFS는 실제로 을 더 빨리 으로 가져오고을 얻습니다. 그 반대의 경우도 마찬가지입니다. 작은 파일 시스템은 저장된 데이터의 GiB 당 초당 50 KiB의 속도로 버스트 크레디트를 축적합니다.
처리량 아마존에서 EFS는 확장 할 수 있습니다. ...
파열 기능을 파일 시스템 (양자 모두의 시간 길이 및 버스트 속도 환산)를 바로 그 크기에 관한 것이다. 더 큰 파일 시스템은 더 오랜 시간 동안 더 큰 속도로 폭발 할 수 있습니다. 따라서 응용 프로그램이 더 많이 터지려면 (즉, 파일 시스템의 버스트 크레딧이 부족한 경우) 파일 시스템의 크기를 늘려야합니다. 아마존 EFS 아무런 비전이 없다
주
, 그래서 당신이 그것에 더 많은 데이터를 추가 할 필요가 파일 시스템이 더 크게 만들 수 있습니다.
그래서, 2 지브 파일 시스템을 위해, 당신은 매일 데이터의 매우 작은 금액을 전송하여 학점을 고갈거야 :
60 sec/minute ×
60 min/hour ×
24 hr/day ×
0.05 MiB/s per GiB stored ×
2 GiB stored = 8,640 MiB/day
그래서 약 8.6 지브 일 당 모든 데이터 전송입니다 이 파일 시스템은 유지할 수 있습니다.
월간 0.60 달러 만 지불한다는 사실을 기억할 때까지 이상하게 보입니다.
단순히 더 많은 데이터를 저장하여 선형 적으로 성능을 향상시킬 수 있습니다. 계산에 사용되는 파일 시스템 크기는 한 시간에 한 번 업데이트되므로이 경로로 이동하면 몇 시간 내에 업틱이 보일 것입니다.
지금까지 잘 작동 한 이유는 각각의 새로운 파일 시스템이 2.1 TiB에 해당하는 초기 크레딧 잔액이 있다는 것입니다. 이것은 주로 처음에 데이터를로드 할 때 파일 시스템을 빠르게 할 수 있도록하기위한 것이지만, 설명하는 것과 같은 총 저장 용량이 적은 환경에서는 며칠 또는 몇 주 동안 지속되고 갑자기 (분명히) 결국은 시스템이 올바른 기본 동작으로 안정화되는지 확인하십시오.
본질적으로 두 개의 상호 연결된 매개 변수 (총 저장 용량 및 기본 처리량)의 설정에 대해 비용을 지불하고 있습니다. 더 많은 저장 용량을 원하면 더 많은 파일을 저장하고 더 많은 처리량을 원하면 더 많은 파일을 저장하십시오.
EBS를 사용하는 자신의 NFS 또는 glusterfs로 이동하는 것은 의미가 없습니다. @Michael이 "더 많은 파일 저장"에 대해 암시하는 바에 따르면, EFS 저장소에 처리량을 늘리는 데 사용할 수있는 더미 파일을 몇 개만 넣으면됩니다. – mootmoot