উচ্চ লোডের জন্য সেরা sysctl.conf কনফিগারেশন - অত্যন্ত ব্যস্ত সামগ্রী স্ট্রিমিং সার্ভার


9

একটি উচ্চ লোড, অত্যন্ত ব্যস্ত কন্টেন্ট স্ট্রিমিং সার্ভারের জন্য সেরা সিস্টেমেট কনফিগারেশনটি কী? সার্ভারটি অ্যামাজন, এস 3 ইত্যাদির মতো দূরবর্তী সার্ভারগুলি থেকে সামগ্রীটি আনে then তারপরে পিএইচপি ব্যবহার করে সামগ্রীটিকে হার্ড ড্রাইভে সংরক্ষণ না করেই গতিশীলভাবে ব্যবহারকারীকে প্রবাহিত করতে পারে। পিএইচপি ফাইল আনতে সিআরএল ব্যবহার করে, তারপরে এটি একই সাথে স্ট্রিম করতে ফ্লাশ () ব্যবহার করে, তাই খুব বেশি হার্ড ড্রাইভের কাজ হয় না ... কেবল নেটওয়ার্ক এবং ব্যান্ডউইথ।

সার্ভারটি কোয়াড কোর জিয়ন, 1 জিবিটি ফুল ডুপ্লেক্স এনআইসি, 8 জিবি র‌্যাম এবং র‌্যাডে 500 গিগাবাইট 2 রয়েছে। সার্ভারের মেমরির ব্যবহার এবং সিপিইউ লোড বেশ কম।

আমরা এটির উপরে ডেবিয়ান লেনি এবং লাইটটিপিডি 2 চালিয়ে যাচ্ছি (হ্যাঁ আমি এটি এখনও প্রকাশ করি নি :-) জানি) পিএইচপি 5.3.6 সহ এবং পিএইচপি ফাস্টসিগি স্পেন-এফসিগি বাইন্ডের সাথে 4 টি আলাদা ইউনিক্স সকেটের সাথে 20 টি শিশু রয়েছে। এসকিউএফ (সংক্ষিপ্ত কাতারে প্রথম) কনফিগারেশনের এই 4 টি সকেটের মধ্যে ফাস্টসিগির অনুরোধগুলিকে ভারসাম্য বজায় রাখতে লাইটটিপিডি 2 কনফিগারেশনে মোড_বালেন্সার মডিউল সহ সর্বাধিক এফসিগির অনুরোধগুলি 20 হয় 20

আমাদের সার্ভারগুলি প্রচুর পরিমাণে ব্যান্ডউইথ ব্যবহার করে अर्थात নেটওয়ার্ক সংযোগ সারাক্ষণ ব্যস্ত থাকে। 100 থেকে 200 সমান্তরাল সংযোগের পরে, সার্ভারটি ধীর হতে শুরু করে এবং শেষ পর্যন্ত প্রতিক্রিয়াহীন হয়ে ওঠে, সংযোগের সময়সীমা ত্রুটি দেওয়া শুরু করে। যখন আমাদের সিপিএনেল ছিল, আমরা কখনই সময়সীমা ত্রুটি পাই নি, সুতরাং এটি কোনও স্ক্রিপ্টের সমস্যা হতে পারে না। এটি অবশ্যই একটি নেটওয়ার্ক কনফিগারেশন সমস্যা হতে পারে।


লাইটটিপিডি 2 কনফিগারেশন: কর্মী প্রক্রিয়াগুলি = 8, জীবিত অনুরোধগুলি 32 হয়, জীবিত রাখুন অলস সময়সীমা 10 সেকেন্ড এবং সর্বাধিক সংযোগগুলি 8192।

আমাদের বর্তমান sysctl.conf সামগ্রীগুলি হল:

net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1

# Increase maximum amount of memory allocated to shm

kernel.shmmax = 1073741824

# This will increase the amount of memory available for socket input/output queues
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

# you shouldn't be using conntrack on a heavily loaded server anyway, but these are
# suitably high for our uses, insuring that if conntrack gets turned on, the box doesn't die
# net.ipv4.netfilter.ip_conntrack_max = 1048576
#  net.nf_conntrack_max = 1048576

# For Large File Hosting Servers
net.core.wmem_max = 1048576
net.ipv4.tcp_wmem = 4096 87380 524288

ওহ, আমি উল্লেখ করতে ভুলে গেছি, যখন আমি প্রতিক্রিয়াবিহীন বলেছিলাম, আমি বলি, এটি পিএইচপি পৃষ্ঠাগুলি, সূচিপত্রের মতো স্থির পৃষ্ঠাগুলি এবং সার্ভিস-স্ট্যাটাস পৃষ্ঠাগুলি ঠিক কাজ করে না ...
ড্যানিয়েল জনসন

2
আপনার প্রথমে খুঁজে বের করতে হবে ঠিক কী প্রতিক্রিয়াহীনতা সৃষ্টি করছে । এটি সম্পর্কিত কিছু নাও থাকতে পারে sysctls। প্রক্রিয়া বন্ধ হয়ে যাওয়া, স্মৃতিশক্তির অভাব ইত্যাদি প্রক্রিয়া আছে কিনা তা পরীক্ষা করে straceদেখুন এবং তারা কোথায় / কোথায় ঝুলছে।
coredump

তারা ঝুলবে না .. যেমনটা আমি বলেছি, কেবলমাত্র পিএইচপি ফাইলগুলি মৃত হয়ে যায়। সার্ভারের স্থিতি পৃষ্ঠাটি
ড্যানিয়েল জনসন

1
@ বিলাল আপনাকে কীভাবে সবকিছু একসাথে কাজ করে তা যাচাই করতে হবে। এটি লকিংয়ের সমস্যা, একটি ভাগ করা সংস্থান (মেমরি / আইআরকিউ) সমস্যা হতে পারে। এই জাতীয় সমস্যার সমাধান খুঁজে পাওয়া তুচ্ছ নয়।
coredump

2
আপনি এখানে আরও কিছু তথ্য সরবরাহ করতে পারেন? নেটস্ট্যাট-ইন, এথিটল-এস এথ0 (বা আপনার লাইভ ইন্টারফেস যাই হোক না কেন)। আপনার সার্ভারটি (মেমরি লাইন) ধীর করে দিলে শীর্ষগুলি কী দেখায়? এবং - আপনি সার্ভার হার্ডওয়্যার সম্পর্কে বিশদ দিতে পারেন? ব্র্যান্ড / প্রকার, নেটওয়ার্ক কার্ডের ধরণ, আপনি ব্যবহার করতে পারেন এমন অন্যান্য নেটওয়ার্ক কার্ড রয়েছে?
নিলস

উত্তর:


5

পারফরম্যান্স টিউনিং এবং এর মতো বোতল ঘাড় সনাক্তকরণ একটি সমাধান করা শক্ত সমস্যা এবং এটি নির্ণয়ের জন্য প্রায়শই প্রচুর তথ্যের প্রয়োজন হয়। প্রক্রিয়াটির চাবিকাঠিটি হ'ল এটি যে প্রক্রিয়াটি ব্যবহার করে থাকে সেখান দিয়ে যাওয়া এবং আপনি কী উত্সটি শেষ হয়ে যাচ্ছেন তা খুঁজে পেতে পারেন কিনা তা দেখুন। আপনি যখন বলেছিলেন সার্ভারটি পিএইচপি-র জন্য প্রতিক্রিয়াহীন, কিন্তু এইচটিএমএল এখনও পরিবেশন করে, এটি একটি আকর্ষণীয় ডেটা পয়েন্ট। কীভাবে সেগুলি পরিবেশন করা হয় তার মধ্যে আলাদা কী? এটি সূক্ষ্ম নেটওয়ার্ক বাফারকে ছাড়িয়ে যেতে পারে, বা এটি এর চেয়ে আরও বেসিক হতে পারে। আপনি হয়ত কেবলমাত্র 20 শিশু এফসিগি চাইল্ড প্রক্রিয়া সীমাটি নিঃশেষ করে দিয়ে গেছেন এবং এগুলি সকলেই ডেটা পরিবেশন করতে ব্যস্ত, যখন নতুন অনুরোধগুলি শোনার কাতারে জ্যাম হয়ে যাচ্ছে (এবং শেষ পর্যন্ত সময় নির্ধারণ করা হচ্ছে) একটি fcgi পিএইচপি প্রক্রিয়াটি আসার অপেক্ষায় রয়েছে।

বাক্সটিতে দৃশ্যমানতা পাওয়ার চেষ্টা করার সময় আসল কৌশলটি সমস্যা দেখা দিলে বাক্সটিতে লগইন করা এবং তথ্য সংগ্রহ করা শুরু করা।

কতগুলি পিএইচপি প্রক্রিয়া চলছে তা সন্ধান করার জন্য আপনার এমন কিছু চালানো উচিত:

ps auxgmww | grep php

এবং আপনি যদি সেগুলি নিজেই গণনা করার চেয়ে তাদের একটি গণনা পেতে চান তবে আপনি এই জাতীয় কিছু করতে পারেন:

ps auxgmww | grep php | wc -l

পারফরম্যান্স টিউনিং সম্পর্কে আপনার আসল প্রশ্নে ফিরে আসুন, syctl.conf পরিবর্তন করার আগে আপনি যখন সমস্যা দেখা দিচ্ছে তখন আপনার সার্ভার আপনাকে কী বলছে তা দেখতে চাইতে পারেন, আপনি নিম্নলিখিতটি দ্বারা এটি খুঁজে পেতে পারেন:

sysctl -a > sysctl.txt

এবং তারপরে আপনার পাঠ্য ফাইলটি দেখুন - এটি সম্পূর্ণ প্রচুর ডেটা, তবে কোনও প্রদত্ত মান টিউন করার আগে সিস্কটল আউটপুটটি বর্তমানে এই টিউনযোগ্যটির জন্য কী ব্যবহার করছে এবং এটি কী কী খরচ করছে তা সম্পর্কে কিছু জানায় কিনা তা দেখুন। একটি উদাহরণ খোলা ফাইলগুলি, যা আপনি এখানে একটি নমুনা আউটপুট দেখতে পারেন:

fs.file-nr = 3456   0   102295

এটি আমাদের বলছে যে আমরা 3456 ফাইল বর্ণনাকারী ব্যবহার করছি, তবে আমাদের সীমা 102295, সুতরাং আমরা আমাদের সীমাটির কাছাকাছি কোথাও নেই। যদি প্রথম সংখ্যাটি 100000 পরিসরে থাকে তবে এটি আপনাকে জানাতে পারে যে আপনি ফাইল বর্ণনাকারীর বাইরে চলেছেন এবং এটিই আপনাকে টিউন করতে হবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.