summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorSid Sijbrandij <sytse@gitlab.com>2018-07-30 20:39:20 +0000
committerSid Sijbrandij <sytse@gitlab.com>2018-07-30 20:39:20 +0000
commite9c9f2e81cae4e67d6938b2a557cb107332dbfaa (patch)
treef63a92c6281974d00ac5b0bc3d9de4c0b6d2e45b /doc
parent06cd8fdf763ed28c6812114d32519c73527d6636 (diff)
parent15fe5c5a3cde7d9ea1e78085699786180b7e1312 (diff)
downloadgitlab-ce-e9c9f2e81cae4e67d6938b2a557cb107332dbfaa.tar.gz
Merge branch 'update-efs-documentation' into 'master'
Clean up AWS EFS documentation See merge request gitlab-org/gitlab-ce!20912
Diffstat (limited to 'doc')
-rw-r--r--doc/administration/high_availability/nfs.md22
-rw-r--r--doc/university/high-availability/aws/README.md6
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