جئت اليوم لأتحدث إليكم مرة أخرى حول واحدة من أكثر خدمات الويب استخدامًا في العالم: خادم الويب Apache2.
إنه موضوع تم الحديث عنه عدة مرات ، لكنني الآن جئت لأخبرك عن ميزة أخرى يجب مراعاتها مع هذه الخدمة: حدود الاتصالات المتزامنة. لا يهم إذا كان لدينا أساسي جدًا أو سفينة فضائية بمعالج i7 و 32 جيجا بايت من ذاكرة الوصول العشوائي ...
سيكون حد الاتصالات المتزامنة دائمًا هو نفسه ما لم نتخذ الإجراءات المناسبة ، مما يعني أنه إذا أردنا توصيل العديد من الأشخاص في نفس الوقت ، فلن نطلب أجهزة جيدة فحسب ، بل أيضًا تهيئة جيدة.
في هذه الحالة ، ليس من الضروري تثبيت أي شيء ، فكل شيء يعتمد على مفاهيم بسيطة يجب مراعاتها لتكوين apache ؛ المفاهيم التي يجب أن تكون واضحة جدًا قبل الرغبة في إجراء أي تغييرات.
أول شيء يجب التفكير فيه هو: ما هي القدرة التي يمتلكها فريقي؟ كم عدد الاتصالات المتزامنة التي يمكن أن تدعمها أجهزتي إذا قمت بفرضها قدر الإمكان؟ كل هذا يعتمد على عامل واحد. ذاكرة الوصول العشوائي (ذاكرة الوصول العشوائي).
كلما زادت ذاكرة الوصول العشوائي ، زاد عدد الاتصالات ، على الرغم من عدم وجود قيمة ثابتة (أي ، عملاء X لكل ذاكرة وصول عشوائي X) ، وهذا هو السبب في أنه من المهم أولاً وقبل كل شيء إجراء بعض الحسابات الصغيرة على خادم الويب الخاص بنا ، باستخدام من أجل معرفة حدودنا.
أول شيء يجب أن تعرفه هو مقدار ذاكرة الوصول العشوائي (RAM) في المتوسط التي يستهلكها كل اتصال بـ Apache ، نظرًا لأن كل اتصال يتم إنشاؤه يفترض استهلاكًا معينًا لذاكرة الوصول العشوائي في النظام ... من الواضح أن جميع الاتصالات لا تستهلك نفس ذاكرة الوصول العشوائي ، والتي يجب على المرء أن يقوم بها الوسائط ... كل هذا يمكن الحصول عليه بالأمر التالي:
ps -ylC apache2 - فرز: rss | awk '{SUM + = 8 دولارات أمريكية ؛ أنا + = 1} نهاية {طباعة SUM / I / 1024} دقيقة
سيتم تمثيل النتيجة التي تم الحصول عليها بالميغابايت وقد تختلف اعتمادًا على عدد الاتصالات النشطة ونوع الصفحات التي تم الوصول إليها وما إلى ذلك ... ولهذا السبب يُنصح بإجراء الاختبار بفتح علامات تبويب مختلفة ؛ كل واحد منهم يعرض محتويات مختلفة إن أمكن. في حالتي ، على سبيل المثال ، كانت النتيجة 9.5458 ، والتي إذا قمنا بتقريبها إلى الأعلى ستكون 10 MB ذاكرة الوصول العشوائي المستهلكة في المتوسط لكل اتصال.
من المهم أيضًا معرفة مقدار ذاكرة الوصول العشوائي (RAM) التي يتم استهلاكها بواسطة باقي العمليات النشطة في النظام ، نظرًا لأن خدمة الويب ليست هي الوحيدة التي تعمل في نظام التشغيل ومن الضروري ترك ذاكرة RAM مجانية على الخادم حتى يتمكن من التنفيذ باقي المهام. يمكن الحصول على ذلك بالأمر الموضح أدناه:
ps -N -ylC apache2 - الترتيب: rss | awk "{SUM + = $ 8} النهاية {print SUM / 1024}"
سيتم تمثيل النتيجة التي تم الحصول عليها أيضًا بالميغابايت ، وستظهر لنا بدقة مقدار ذاكرة الوصول العشوائي التي تستهلكها بقية العمليات ؛ في حالتي 800 MB. باستخدام هذه المعلومات ، يمكننا إجراء حساب عام لعدد الاتصالات المتزامنة التي يمكن أن نحصل عليها ؛ أحسب أننا سنحصل عليه عن طريق عملية بسيطة للغاية.
(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN
مع وجود هذه الصيغة في متناول اليد ، دعنا نتخيل أن لدينا جهاز كمبيوتر به ذاكرة وصول عشوائي سعتها 4 جيجابايت ، أي 4096 ميجابايت وأن جهاز الكمبيوتر الخاص بنا أظهر النتائج المذكورة أعلاه ؛ سيكون الحساب:
(4096 - 800) / 10 = 329 اتصالاً متزامناً
تكمن المشكلة في هذا الحساب في أنه مفرط للغاية ، لأنه سيستهلك كل ذاكرة الوصول العشوائي (مما يجعل الخادم يستهلك المبادلة) وأيضًا ، في حالة وجود قاعدة بيانات ، مثل MySQL أو أي قاعدة بيانات أخرى ، فإن الاتصالات بها ستستهلك أيضًا ذاكرة الوصول العشوائي ، والتي يمكن من خلالها اعتبار الرقم الذي تم الحصول عليه رقمًا مثاليًا. لذلك ، من أجل تحرير الذاكرة للعمليات الإضافية المحتملة والنظر أيضًا في إمكانية تنفيذ الاتصالات بقاعدة البيانات ، سنقلل عدد الاتصالات إلى 250.
الآن بعد أن أصبح لدينا أقصى عدد من الاتصالات المتزامنة لدينا ، سيتعين علينا إعداد Apache حتى نتمكن من تلقي هذا الرقم ، وهو ما يتم في ملف التكوين الخاص بهذه المكالمة apache2.conf، والتي يتم استضافتها في / الخ / اباتشي 2.
يتبع الملف المعني بنية تستند إلى وحدات، كل واحد يحمل اسمه المقابل ، لكننا سنهتم فقط بواحد منهم ، اسمه mpm_prefork_module. تحتوي الوحدة المعنية على البيانات التالية افتراضيًا:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0
تحتوي هذه الوحدة على سلسلة من المعلمات المهمة جدًا ، على الرغم من وجود واحدة منها تهمنا بشكل خاص ، تسمى Maxclients. تحدد هذه المعلمة الحد الأقصى لعدد الاتصالات المتزامنة ويجب تعديلها إلى 250.
أحد التفاصيل التي يجب مراعاتها هو أنه عندما يتم تحديد قيمة أخرى غير القيمة الافتراضية في المعلمة المذكورة ، فمن الضروري إضافة قيمة أخرى قبل هذه القيمة. هذه المعلمة تسمى ServerLimit وتعيين حد الاتصالات التي يمكن للخادم "الاحتفاظ بها" حتى عندما يكون خارج الحد.
يجب أن تكون معلمة ServerLimit دائمًا أعلى قليلاً من MaxClients وهنا ، نظرًا لوجود مساحة صغيرة للمناورة ، فإن الحد الأقصى 270. هذا من شأنه أن يجعل الوحدة تبدو كما يلي:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0
الآن سيكون من الضروري فقط إعادة تشغيل خدمة Apache باستخدام الأمر:
/etc/init.d/apache2 إعادة التشغيل
مع هذا يمكننا بالفعل الاستمتاع بخادم الويب الخاص بنا.
تحية.
شكرا على المنشور!
أنا سعيد لأنك وجدتها مفيدة.
تحية.
هناك طريقة للتجمع مع Apache وخادمين ، هل يمكنك شرح كيفية عملها؟
على الرغم من أنني قرأت بعض النظريات حول هذا الموضوع ، إلا أنني لم أقم بتطبيقها على الإطلاق. ومع ذلك ، ربما يمكن أن تقدم لك هذه المقالة بعض الإرشادات في هذا الصدد ، على الرغم من أنني أكرر أنه لم تتح لي الفرصة لتطبيقها:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
لقد طلبت فترة ، إذا لم تحلها ؛ لديّ مخطط موازنة مع طرف ثالث يعمل كنظام ملفات ، فأنت توجه المجلدات الموجودة في var / www / html / (في حالتي) إلى نظام الملفات ، بحيث يتشاركون نفس المعلومات ، وربما ستحتاج إلى عنوان IP افتراضي يستجيب وإعادة التوجيه إلى ips of the apaches ، لذلك يمكنك شغل haproxy وإذا كنت تريده بتوافر عالٍ ، فيمكنك دمج Keepalive في حالة سقوط أحدهما أو استمرار الآخر في الاستجابة أو أيضًا إذا كان لديك بالفعل مجال للتطبيق ، يمكنك الموازنة مع الجنيه القيام بالخلفيات للخادمين ، لحالات محددة مثل moodle أو تطبيقات معينة تتصل بقاعدة بيانات في mysql ، سيكون عليك إنشاء مستخدم لكل خادم تطبيق يشير إلى نفس قاعدة البيانات.
شكراً جزيلاً لك على المنشور ، أنت محق تمامًا ، ذاكرة الوصول العشوائي هي الحساب الأساسي ، على الرغم من أنني أتخيل أننا نحسب أيضًا الحد الأقصى لعدد العمليات التي يمكن لمعالجنا التعامل معها (بالطبع ، أولاً نقوم بحساب الذاكرة الرئيسية) وكيف سيتم توزيع القرص صعب (مثال على الأقسام / var = 1TR).
أنت على حق؛ كل شيء مهم ، مثل التحكم في درجة الحرارة من بين أشياء أخرى. من الواضح أن المعالج القوي يمكنه أداء عدد أكبر من المهام في وقت واحد بكفاءة عالية ، ولكن الهدف من هذا المنشور هو شرح أهمية ذاكرة الوصول العشوائي فيما يتعلق بعدد الاتصالات المتزامنة.
هناك طريقة جيدة للتحكم في كل هذه العوامل ومعرفة ما إذا كان معالجنا غير مشبع أو إذا كان لدينا القليل من ذاكرة الوصول العشوائي المجانية ، سيكون باستخدام برنامج bash النصي. ربما يكون هذا المنشور الذي قمت بإنشائه قبل بضعة أيام حول هذا الموضوع ممتعًا بالنسبة لك ، والذي أتركه لك في الرابط التالي ؛ إنها مراقبة عالمية ولكنها قد تكون ممتعة لشخص ما:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
تحياتي
ملاحظة جيدة جدا ، شكرا جزيلا لك!
شكرا جزيلا! آمل أن تكون قد تمكنت من الاستفادة منه.
لا أريد أن أكون أحمق ...
... ولكن بزيادة عدد الاتصالات ، فإنك لا تترك أكثر عرضة لهجمات DDoS؟
إنه ليس سؤال كريتين هادئ. الحقيقة هي أنه من خلال زيادة عدد الاتصالات المتزامنة ، نقوم جزئيًا بتحصين Apache ضد هجمات DDOS ، لأنه يجب أن تأخذ في الاعتبار أن عدد الاتصالات المتزامنة القصوى التي تم إنشاؤها على الخادم هو عدد الاتصالات القصوى الإجمالية ، وليس تلك القادمة من مستخدم واحد. وبالتالي ، بينما في البداية لا يمكننا دعم سوى 150 اتصالًا متزامنًا (سواء كانت اتصالات من مصدر شرعي أم لا) الآن يمكننا الاعتماد على أكبر عدد يدعمه خادمنا ، مما يتطلب عددًا أكبر من الاتصالات في نفس الوقت لتكون بدون خدمة. من الواضح أن زيادة الحد الأقصى لعدد الاتصالات ليست طريقة لحماية نفسك من هذا النوع من الهجوم ، ولكن عليك بدلاً من ذلك تنفيذ سياسات جدار الحماية. على سبيل المثال ، إذا كانت خدمة الويب التي تريد وضعها ستتعرض للإنترنت ، فإن الإجراء الأمني الذي يمكن تنفيذه سيكون إضافة هذه الخطوط إلى جدار الحماية الخاص بنا:
iptables -A INPUT -p tcp –syn –dport 80 -m connlimit -connlimit-up to 10 -m state-state NEW -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -m state-state ESTABLISHED، ذات الصلة -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -j DROP
تتمثل إحدى خصائص هجمات DDoS في أن المهاجم يمكن أن يظهر لإرسال حزم من عدة اتجاهات مختلفة ، مما يمنع تدفق الحزم من اتجاه واحد فقط.
أنت محق بمعنى أن جدار الحماية مثل الذي قمت بإعداده ليس فعالًا للغاية ضد هجوم DDOS ، لأنه يأتي من مصادر مختلفة. ومع ذلك ، من الأفضل قصر عدد الاتصالات على 10 لكل من هذه المصادر بدلاً من عدم وجود حد ، مما يجعل كل مصدر قادرًا على إنشاء مائة اتصال أو أكثر.
على أي حال ، فإن مجموعة السؤال هي أنه كلما زادت الاتصالات المتزامنة التي يدعمها الخادم ، زادت صعوبة هدمه بهجوم DDOS ، مما يجعل الأمر أكثر صعوبة على الصفحة من قبل المهاجم.
تحية.
حسن. في الوقت الحالي ، أواصل استخدام NGINX على موقعي حتى لا أقوم بتعذيب VPS لدي.
مشاركة لطيفة @ Drassill!
كنت أرغب في المساهمة بشيء ربما يكون إحصائيًا أكثر من التكوين.
على الرغم من أن الطريقة الأسهل والأسرع لحساب معامل الاستهلاك هي باستخدام المتوسط ، ربما يمكننا أن نكون أكثر صرامة ونستخدم "الوسيط" بدلاً من "المتوسط". ما الذي سينقذنا منه؟ أن تنفجر الأرقام في حالة استنفاد الاتصال الكثير من الذاكرة. على سبيل المثال ، افترض أن العملاء التاليين يستهلكون القيم التالية ، في وحدة الذاكرة التي يريدونها (KB ، MB ، MiB ، إلخ):
10 ، 15 ، 150 ، 5 ، 7 ، 10 ، 11 ، 12
المتوسط سيعطي حوالي 30
وهذا لأن لدينا نهاية كبيرة جدًا (150) ، والحسابات مجنونة. يتكون الوسيط من ترتيب هذه البيانات ، وقسمة عدد العينات على 2 (مركزنا) ثم الحصول على رقم هذا الموضع. مع هذا سيكون لدينا شيء مثل
5 ، 7 ، 10 ، 10 ، 11 ، 12 ، 15 ، 150
لذا فإن المتوسط سيكون: 8/2 = 4 أي ~ 10
هنا يمكنك أن ترى أنه بغض النظر عن مدى جنون التطرف ، فإنه سيعطينا دائمًا قيمة أكثر واقعية. إذا أضفنا عميلًا يستهلك 200 ، فسيكون الوسيط 11 ، بينما قد يذهب المتوسط إلى …….
إنها مجرد مساهمة ، وهي قابلة للنقاش للغاية ، لأنها مع التوصيلات غير مشدودة.
عناق الناس لينوكسيرا 🙂
مرحبًا ، لقد واجهت مشكلة في الخادم المخصص الخاص بي ، وهي أنه في كل مرة يقترب فيها ما يقرب من 250 شخصًا عبر الإنترنت ، وفقًا لتحليلات google في الوقت الفعلي ، ينهار الخادم الخاص بي ويصبح الاتصال بطيئًا حتى ينخفض الاتصال بالموقع ولا يقوم بتحميل أكثر من هذا العدد من المستخدمين عبر الإنترنت ، ولكن عندما أرى أداء الخادم المخصص وهو 8 جيجابايت من ذاكرة الوصول العشوائي ، فإنه يظهر 10٪ من الاستخدام ، وحدة المعالجة المركزية: 5٪ من الاستخدام والقرص الصلب في: 1.99 ٪ من الاستخدام.
هل بإمكانك مساعدتي؟ لا أجد ما يجب فعله ، فهل القيام بهذه الخطوات هو الحل؟
جيد كارلوس.
تكون المشكلة التي تصفها شائعة جدًا عندما لا يتم إعداد الخادم بشكل صحيح. من المحتمل أن يقبل الخادم الخاص بك عددًا أقل بكثير من الاتصالات المتزامنة وعندما يصل إلى 250 اتصالًا سيتعطل. باتباع الدليل ، يجب أن تكون قادرًا على حل المشكلة ، على الرغم من أنه إذا كان لديك قاعدة بيانات على هذا الخادم ، فسيتعين عليك أيضًا تحسين قاعدة البيانات هذه.
تحية.
Drassill ، لقد أجريت التكوين الذي ذكرته وكان مرضيًا ، أمس وصلت إلى 280 مستخدمًا عبر الإنترنت ولم يتم تعليق الخادم ، وأنا سعيد جدًا بهذه النتيجة ، وأريد أيضًا أن أفعل الشيء الآخر الذي تخبرني به لتحسين قاعدة البيانات ، ¿ كيف يمكنني تحقيق ذلك؟
مفهوم قاعدة البيانات مفتوح تمامًا ؛ استخدام mysql يختلف عن postgres (على سبيل المثال). من الواضح أنني لا أعرف كل قواعد البيانات. لقد جربت mysql و postgres ، وستعتمد زيادة الاتصالات المتزامنة في هذه على معلمة اتصالات max ؛ سيتم تحسين mysql في /etc/my.conf وسيتعين تغيير اتصالات الحد الأقصى للمعامل (من بين أمور أخرى). بالنسبة إلى postgres بدلاً من ذلك ، لدي مقال على مدونتي يشرح كيفية تحسينها التي قد تكون مفيدة لك أو يمكنك استخدامها كمرجع لقاعدة البيانات الخاصة بك:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
تحية.
مرحبًا ، عندما أطرح الأمر الأول ، فإنه يظهر لي القيمة 0. ماذا يمكن أن يكون؟
شكرا لهذا المنصب.
يا له من دليل جيد ، هذه المعلومات جزء مما أبحث عنه ... شكرًا!
ولكن الآن ، إذا أردت أنه عند تجاوز هؤلاء الزائرين الـ 250 ، ينتقل الزائر 251 إلى صفحة انتظار أو قائمة انتظار افتراضية ، فهل يمكنني القيام بذلك من نفس التكوين؟
تحياتي وشكري!