أود الاستفادة من خبرتك حول كيفية مواصلة توسيع نطاق أجهزتنا.
هذه هي بياناتنا الأساسية:
2.2 مليون منشور تنمو حاليًا بحوالي 80 ألف شهريًا
35 ألف مستخدم، ينمون بحوالي 1.5 ألف شهريًا
نحن نعمل حاليًا على جهاز افتراضي من Hetzner بـ 8 أنوية حصرية و 32 جيجابايت من ذاكرة الوصول العشوائي. بدأنا نرى قيودًا في ديسمبر مع اتصالات عامل Nginx أولاً وزدناها من 768 افتراضيًا إلى 1536. وصلنا إلى هذا الحد مرة أخرى بالأمس وزدناها إلى 3072 الآن. بعد هذه التغييرات، تسير الأمور بسلاسة مرة أخرى ولكننا نقترب من حد استخدام الخادم بنسبة 100٪.
تم تعيين db_work_mem على 80 ميجابايت، و db_shared_buffers على 8192 ميجابايت. نحن لا نستخدم ذاكرتنا المتاحة على الإطلاق ولكنني لست متأكدًا مما إذا كانت هناك مساحة لاستخدام المزيد والاستفادة منها. أفكار؟
#~> free -m
total used free shared buff/cache available
Mem: 31360 6105 1241 8423 24013 16412
خيار التوسع السهل التالي مع Hetzner سيكون 16 نواة و 64 جيجابايت من ذاكرة الوصول العشوائي وهو أمر جيد بالنسبة لنا من حيث التكاليف، لكنني أتساءل عما إذا كان لا يزال من المنطقي التوسع رأسيًا. كنت أفكر فيما إذا كان فصل التطبيق وقاعدة البيانات إلى خوادم مختلفة لن يكون منطقيًا أكثر أو ما إذا كان سيؤدي إلى المزيد من الصعوبات.
لأنني أخطط للمستقبل. قد لا نحتاج إلى التوسع الآن ولكن بالنظر إلى النمو الذي نراه والحاجة المتزايدة للموارد التي شهدناها في الماضي، فأنا فقط أخطط للمستقبل الآن للتفكير في الخطوات التالية الممكنة.
بشكل أساسي وحدة المعالجة المركزية - بعد تحديث اليوم، نعود من الحمل ~ 8-9 في ساعات الذروة إلى ما يبدو أنه ~ 6ish الآن.
12 مليون شهريًا نمت من 6.5 مليون شهريًا قبل عام.
سأعود إلى مخرجات sar في وقت لاحق، لم أكن أقوم بتشغيلها.
نعم، أفعل، ولكن ليس في ساعات الذروة بعد. سأحصل عليها بحلول الغد.
لقد تم تقليل استخدام وحدة المعالجة المركزية بالتأكيد منذ أن قمت بزيادة اتصالات العاملين بالأمس - لست متأكدًا من مقدارها.
12:00:01 AM CPU %user %nice %system %iowait %steal %idle
08:45:01 AM all 40.22 2.21 7.44 0.27 0.00 49.86
08:55:01 AM all 42.84 2.89 8.02 0.16 0.00 46.09
09:05:01 AM all 38.81 0.86 7.68 0.12 0.00 52.53
09:15:01 AM all 38.80 0.70 7.66 0.10 0.00 52.73
09:25:01 AM all 38.71 2.14 7.88 0.12 0.00 51.16
09:35:01 AM all 38.74 0.84 7.86 0.09 0.00 52.47
09:45:01 AM all 40.31 1.07 7.95 0.10 0.00 50.57
09:55:01 AM all 40.03 1.37 7.90 0.08 0.00 50.62
10:05:01 AM all 39.00 1.29 7.90 0.09 0.00 51.72
10:15:01 AM all 40.26 2.68 8.07 0.09 0.00 48.91
10:25:01 AM all 41.59 0.93 8.31 0.08 0.00 49.09
10:35:01 AM all 40.39 1.55 8.25 0.07 0.00 49.73
10:45:01 AM all 45.44 2.37 9.08 0.08 0.00 43.03
10:55:01 AM all 50.56 2.20 9.23 0.06 0.00 37.95
11:05:01 AM all 41.82 1.54 8.55 0.08 0.00 48.02
11:15:01 AM all 38.74 1.54 8.11 0.10 0.00 51.50
11:25:01 AM all 45.41 1.59 9.27 0.19 0.00 43.55
11:35:01 AM all 38.45 1.78 8.20 0.11 0.00 51.45
11:45:01 AM all 41.03 1.60 8.48 0.14 0.00 48.75
11:55:01 AM all 40.65 1.17 8.36 0.15 0.00 49.67
12:05:01 PM all 40.03 1.29 8.40 0.13 0.00 50.15
12:15:01 PM all 40.47 1.10 8.19 0.11 0.00 50.13
كنت أشك في أن Postgres لم يكن يحصل على ذاكرة كافية، مما قد يؤدي إلى ارتفاع نسبة %iowait.
ولكن نظرًا لأن مخرجات sar أعلاه لا تشير إلى نظام مثقل بالأعباء، فسيتعين علينا انتظار إحصائيات جديدة.
أحاول مساعدة شخص آخر في مشاكل الأداء. لقد قمنا بزيادة حجم مخزن PostgreSQL المؤقت. أعتقد أن ذلك ساعد قليلاً ولكن ملف تعريف الأداء المصغر لا يزال يظهر أكثر من 300 مللي ثانية. استخدام وحدة المعالجة المركزية حوالي 30٪ لـ 16 وحدة معالجة مركزية.
أعتقد أنه إذا حققنا أقل من 50 مللي ثانية في جميع الحالات بغض النظر عن ساعات الذروة، فسأعتبر ذلك وقت استجابة سريع للخادم. سيكون باقي الموقع أسرع لأن كل شيء يعتمد على وقت الاستجابة الأولي للخادم.
وسيكون مثاليًا للغاية إذا ظل أقل من 50 مللي ثانية لجميع المستخدمين الجغرافيين وظل ثابتًا. في الوقت الحالي، يستمر في القفز وغالبًا ما يكون أعلى، ويبدو أن هذه هي المشكلة الكبيرة لكونه بطيئًا.
كمراجعة سريعة للأيام القليلة الماضية، استمرت الأمور بسلاسة باستثناء حوالي نصف ساعة هذا المساء. لم أكن في الخادم بنفسي في ذلك الوقت ولكننا واجهنا مهلات من الواجهة الخلفية المبلغ عنها في سجل nginx. يُظهر sar استخدامًا أعلى قليلاً للنظام ولكن لا يوجد حمل عام لوحدة المعالجة المركزية. لست متأكدًا مما كان ذلك ولكنه بدا أنه يمنع unicorn/redis/postgres من العمل بسلاسة.
03:55:01 PM all 34.99 1.87 6.67 0.12 0.00 56.35
04:05:01 PM all 33.99 0.35 6.52 0.31 0.00 58.82
04:15:01 PM all 35.24 1.17 7.14 0.13 0.00 56.31
04:25:02 PM all 36.45 0.63 7.15 0.13 0.00 55.65
> 04:35:01 PM all 39.09 0.71 16.78 0.11 0.00 43.32
> 04:45:01 PM all 35.53 0.95 20.16 0.08 0.00 43.27
> 04:55:01 PM all 41.64 4.29 15.44 0.24 0.00 38.39
05:05:01 PM all 36.75 2.47 7.78 0.13 0.00 52.87
05:15:01 PM all 35.96 1.29 7.81 0.10 0.00 54.85
05:25:01 PM all 38.69 1.35 8.00 0.09 0.00 51.87
05:35:01 PM all 37.01 4.53 7.92 0.07 0.00 50.46
إنها الأسطر المميزة بعلامة “>”.
لا أرى أي حركة مرور عالية في ذلك الوقت، لذا أنا في حيرة من أمري بشأن ما كان يحدث ولكنه كان يحدث بالفعل فقط خلال تلك النصف ساعة.
بشكل عام، عند النظر إلى وقت وحدة المعالجة المركزية، يتصدر Redis ويستخدم بشكل عام جزءًا كبيرًا من وحدة المعالجة المركزية. لست متأكدًا مما إذا كان هناك أي شيء يمكن فعله حيال ذلك. عادة ما يكون عند حوالي 20-25٪ ويصل إلى 35٪ هنا وهناك.
1721566 uuidd 20 0 2035M 1458M 1952 S 16.1 4.6 16h22:37 /usr/bin/redis-server *:6379
1721578 www-data 20 0 108M 69100 12516 S 6.7 0.2 6h32:27 nginx: worker process
2853756 1000 20 0 1355M 444M 19356 R 63.7 1.4 2h38:10 unicorn worker[0] -E production -c config/unicorn.conf.rb
2854380 1000 20 0 1267M 409M 18768 S 41.6 1.3 2h19:45 unicorn worker[4] -E production -c config/unicorn.conf.rb
1721598 1000 20 0 592M 285M 5192 S 1.3 0.9 2h08:53 unicorn master -E production -c config/unicorn.conf.rb
575 root 20 0 1747M 20468 5040 S 0.7 0.1 2h01:02 /usr/bin/containerd
2854731 1000 20 0 1280M 399M 17880 S 36.9 1.3 1h57:52 unicorn worker[7] -E production -c config/unicorn.conf.rb
1721841 1000 20 0 592M 285M 5192 S 0.7 0.9 1h49:49 unicorn master -E production -c config/unicorn.conf.rb
2855284 1000 20 0 1287M 425M 18396 S 18.8 1.4 1h35:02 unicorn worker[3] -E production -c config/unicorn.conf.rb
2856414 1000 20 0 1223M 391M 19268 S 13.4 1.2 1h14:50 unicorn worker[2] -E production -c config/unicorn.conf.rb
2856478 1000 20 0 1207M 401M 21120 S 5.4 1.3 58:42.50 unicorn worker[5] -E production -c config/unicorn.conf.rb
2856503 1000 20 0 1215M 389M 18980 S 4.7 1.2 47:22.95 unicorn worker[1] -E production -c config/unicorn.conf.rb
1721581 www-data 20 0 69888 28636 13368 S 0.0 0.1 44:49.50 nginx: worker process
2857467 1000 20 0 1199M 385M 18112 S 4.0 1.2 39:23.87 unicorn worker[6] -E production -c config/unicorn.conf.rb
1721594 _apt 20 0 8479M 20036 18128 S 1.3 0.1 32:55.29 postgres: 13/main: walwriter
580 root 20 0 1747M 20468 5040 S 0.0 0.1 32:15.27 /usr/bin/containerd
متوسط الحمل العام هو 5 على المدى الطويل الآن ولكنني ما زلت أراه يرتفع إلى 8 أو 9 من وقت لآخر.
بخصوص أداة mini profiler. كنت أتحدث عن وقت التحميل الإجمالي. وقت استجابة الخادم (الطلب الأولي) عادة ما يكون أقل من 10 مللي ثانية من جانبنا. أحيانًا أعلى قليلاً ولكنني لم أرَ أكثر من 20 مللي ثانية في آخر فحوصاتي. وقت التحميل الإجمالي يصل إلى 800 مللي ثانية أحيانًا، ونادرًا ما يتجاوز 1000 مللي ثانية.
النظر فقط إلى منطقة جغرافية واحدة حيث ليس لدينا أعداد كبيرة من المستخدمين خارج تلك المنطقة.
