diff options
| author | Joshua Lambert <joshua@gitlab.com> | 2018-07-30 15:24:34 -0400 |
|---|---|---|
| committer | Joshua Lambert <joshua@gitlab.com> | 2018-07-30 15:24:34 -0400 |
| commit | 15fe5c5a3cde7d9ea1e78085699786180b7e1312 (patch) | |
| tree | e0e45e480e126622e300b0649ab35cec78b165a1 | |
| parent | 934f1f69022ab39b62161d26c4d1d485bd66b09f (diff) | |
| download | gitlab-ce-15fe5c5a3cde7d9ea1e78085699786180b7e1312.tar.gz | |
Clean up AWS EFS documentation
| -rw-r--r-- | doc/administration/high_availability/nfs.md | 22 | ||||
| -rw-r--r-- | doc/university/high-availability/aws/README.md | 6 |
2 files changed, 7 insertions, 21 deletions
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index 87e96b71dd4..387c3fb6a5b 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -39,23 +39,11 @@ Our support team will not be able to assist on performance issues related to file system access. Customers and users have reported that AWS EFS does not perform well for GitLab's -use-case. There are several issues that can cause problems. For these reasons -GitLab does not recommend using EFS with GitLab. - -- EFS bases allowed IOPS on volume size. The larger the volume, the more IOPS - are allocated. For smaller volumes, users may experience decent performance - for a period of time due to 'Burst Credits'. Over a period of weeks to months - credits may run out and performance will bottom out. -- To keep "Burst Credits" available, it may be necessary to provision more space - with 'dummy data'. However, this may get expensive. -- Another option to maintain "Burst Credits" is to use FS Cache on the server so - that AWS doesn't always have to go into EFS to access files. -- For larger volumes, allocated IOPS may not be the problem. Workloads where - many small files are written in a serialized manner are not well-suited for EFS. - EBS with an NFS server on top will perform much better. - -In addition, avoid storing GitLab log files (e.g. those in `/var/log/gitlab`) -because this will also affect performance. We recommend that the log files be +use-case. Workloads where many small files are written in a serialized manner, like `git`, +are not well-suited for EFS. EBS with an NFS server on top will perform much better. + +If you do choose to use EFS, avoid storing GitLab log files (e.g. those in `/var/log/gitlab`) +there because this will also affect performance. We recommend that the log files be stored on a local volume. For more details on another person's experience with EFS, see diff --git a/doc/university/high-availability/aws/README.md b/doc/university/high-availability/aws/README.md index dc045961ed7..8f7bb8636c5 100644 --- a/doc/university/high-availability/aws/README.md +++ b/doc/university/high-availability/aws/README.md @@ -2,10 +2,8 @@ comments: false --- -DANGER: This guide exists for reference of how an AWS deployment could work. -We are currently seeing very slow EFS access performance which causes GitLab to -be 5-10x slower than using NFS or Local disk. We _do not_ recommend follow this -guide at this time. +> **Note**: We **do not** recommend using the AWS Elastic File System (EFS), as it can result +in [significantly degraded performance](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/administration/high_availability/nfs.md#aws-elastic-file-system). # High Availability on AWS |