postgresql vps
قواعد البيانات وأحمال العمل في الذاكرة
عند تجاوز حجم معيّن لمجموعة العمل، فإن التحسين الوحيد الذي يهم هو وضع كل شيء في الذاكرة العشوائية. توفر FORGE ما يصل إلى ستة عشر غيغابايت لكل نواة من ذاكرة ECC المسجلة مع صفحات ضخمة مُهيأة مسبقًا وتوزيعًا مراعيًا لـ NUMA، وهو ما تحتاجه PostgreSQL وRedis وClickHouse وكومة JVM الكبيرة. تحتها تخزين NVMe من الجيل الخامس بتكوين RAID10، لذا فإن عمليات الكتابة التي تصل إلى القرص ليست عنق الزجاجة أيضًا.
لماذا هذا التكوين
FORGE مع تقارب أحادي NUMA يبقي الوصول إلى الذاكرة محليًا داخل المقبس الذي يقوم بالعمل. أضف نسخًا احتياطية ليلية مع ثلاثين نقطة استعادة، لأن نمط الفشل الذي ستواجهه فعليًا هو ترحيل سيئ، وليس قرصًا تالفًا.
ما سننشره
الحجم
اضبط حجم الذاكرة العشوائية حسب مجموعة العمل، وليس قاعدة البيانات. مجموعة العمل هي صفحات الفهرس الساخنة بالإضافة إلى الصفوف التي يتم الوصول إليها فعليًا، وغالبًا ما تكون 10-20% من مجموعة بيانات OLTP بحجم 2 تيرابايت. اضبط InnoDB buffer pool على 70-75% من الذاكرة العشوائية، أو shared_buffers في Postgres على 25% ودع ذاكرة التخزين المؤقت للصفحات تحتوي الباقي. تصل FORGE إلى 16 غيغابايت لكل نواة، لذا فإن buffer pool بسعة 512 غيغابايت يستقر على حوالي 700 غيغابايت من الذاكرة العشوائية و44 نواة على الأقل. إذا تجاوزت القراءات المتخلفة عن الذاكرة المخبأة 1% من الوقت، فاشترِ ذاكرة عشوائية.
الصفحات الضخمة، ولماذا THP ليس نفس الشيء
buffer pool بسعة 256 غيغابايت مرسوم في صفحات 4 كيلوبايت يتطلب حوالي 64 مليون إدخال في جدول الصفحات. لا يمكن أن تحمل TLB جزءًا ذا معنى من ذلك، لذا يدفع الوصول العشوائي ثمن التنقل عبر الصفحات في معظم عمليات البحث. تقلل الصفحات الضخمة الثابتة بحجم 2 ميغابايت عدد الإدخالات بمقدار 512 وتقلل معها عمليات التنقل — توقع انخفاضًا ملموسًا في وقت وحدة المعالجة المركزية لكل استعلام على التجمعات الكبيرة. خصصها عند الإقلاع عبر vm.nr_hugepages، بحجم كافٍ للتجمع بالإضافة إلى حوالي 10%، وأعطِ مستخدم قاعدة البيانات حد memlock. تحقق الصفحات الضخمة الشفافة نفس التعيين لكنها تفعل ذلك بشكل انتهازي، مع توقف بسبب الضغط. عطّل THP وخصص بشكل صريح.
مجموعة العمل، مقاسة وليست تخمينية
لا تقم بتقدير مجموعة العمل من حجم دليل البيانات. قسها. في Postgres، يخبرك pg_buffercache بالعلاقات التي تشغل shared_buffers، ونسبة heap_blks_hit إلى heap_blks_read في pg_statio_user_tables تعطي معدل إصابة ذاكرة التخزين المؤقت لكل جدول. في MySQL، يعطي Innodb_buffer_pool_reads مقابل Innodb_buffer_pool_read_requests نفس الإشارة. فوق 99% تكون في الذاكرة وإضافة ذاكرة عشوائية تشتري القليل. بين 95% و99% تكون على حافة الهاوية، ويمكن لاستعلام واحد بدون فهرس أن يدفعك فوقها. أقل من 95% كل رقم زمن استجابة لديك هو في الحقيقة رقم زمن استجابة للقرص متنكرًا.
ما الذي يحدث بشكل خاطئ
- ترك صفحات ضخمة شفافة ممكّنة. يؤدي تجزئة THP إلى إيقاف العملية مؤقتًا لمللي ثانية في لحظات غير متوقعة، وهو ما يظهر كزمن استجابة p99 لا يمكن لأحد تفسيره. اضبطها على never وخصص صفحات ضخمة ثابتة بدلاً من ذلك.
- تجاهل NUMA على FORGE ثنائي المقبس. تستقر ذاكرة التخزين المؤقت على عقدة واحدة، وتقرأ نصف النوى عبر الترابط، وقد يقوم MySQL بالتبديل على الرغم من وجود ذاكرة خالية. استخدم numactl --interleave=all أو اربط صراحةً.
- حجم IOPS بناءً على متوسط الإنتاجية. نقاط التفتيش والتفريغ والنسخ الاحتياطي هي القمم التي تهم. تجمع يتعامل مع الحالة المستقرة جيدًا سيوقف المثيل بأكمله أثناء تدفق نقطة تفتيش.
اضبط الجهاز
- جدولة المعالج — Single-NUMA-node affinity · 14 €
- النسخ الاحتياطي — Daily backup, 30 restore points · 11 €
- كل شيء آخر — Second-resolution metrics + alerting · 5 €
- التخزين والتشفير — ZFS with hourly snapshots · 7 €
المزيد
مصمم لمهام محددة
استضافة خوادم الألعاب
معدل التكرار (Tick rate) مشكلة نواة واحدة. كل شيء آخر مجرد ضوضاء.
VPS للتداول ومنخفض زمن الاستجابة
المسافة إلى محرك المطابقة، ولا شيء بينك وبين الشبكة.
نقاط نهاية VPN وبروكسي خاصة
نقطة خروج خاصة بك، في ولاية قضائية اخترتها عن قصد.
صناديق البذور والتخزين السائب
تيرابايت لا تزال رخيصة ومنفذ يبقى مفتوحًا.
عقد عمل Kubernetes
رخيص للنواة الواحدة، كثيف، ومتطابق في كل مرة.
استدلال الذكاء الاصطناعي والضبط الدقيق
GPU كاملة، تم تمريرها، على التزام يجعل الحسابات تعمل.