টিউনিং লিনাক্স আইপি রাউটিং পরামিতি - সিক্রেট_ইন্টারওয়াল এবং tcp_mem


30

আমাদের আজ একটি HAProxy ভিএম এর সাথে আমাদের কিছুটা ব্যর্থতা সমস্যা ছিল। আমরা এটি খনন করার পরে, আমরা এটি খুঁজে পেয়েছি:

জানুয়ারী 07 07:41:45 হ্যাপ্রোক্সি 2 কার্নেল: [226818.070059] __রেটলিট: 10 কলব্যাক দমন করা হয়েছে
জানুয়ারী 07 07:41:45 হ্যাপ্রোক্সি 2 কার্নেল: [226818.070064] সকেটের মেমরির বাইরে
জানুয়ারী 07 07:41:47 হ্যাপ্রোক্সি 2 কার্নেল: [226819.560048] সকেটের মেমরির বাইরে
জানুয়ারী 07 07:41:49 হ্যাপ্রোক্সি 2 কার্নেল: [226822.030044] সকেটের মেমরির বাইরে

কোনটি, এই লিঙ্কটির জন্য , আপাতত কম ডিফল্ট সেটিংসের জন্য করতে হয় net.ipv4.tcp_mem। সুতরাং আমরা তাদের ডিফল্টগুলি থেকে 4x বাড়িয়েছি (এটি উবুন্টু সার্ভার, লিনাক্সের স্বাদের বিষয়টি নিশ্চিত কিনা তা নিশ্চিত নয়):

বর্তমান মানগুলি: 45984 61312 91968
নতুন মানগুলি হ'ল: 183936 245248 367872

এর পরে, আমরা একটি উদ্ভট ত্রুটি বার্তা দেখতে শুরু করেছি:

জানুয়ারী 08 08:18:49 haproxy1 কার্নেল: [2291.579726] রুট হ্যাশ চেইনটি খুব দীর্ঘ!
জানুয়ারী 08 08:18:49 haproxy1 কার্নেল: [2291.579732] আপনার গোপন_ইন্টারওয়ালটি সামঞ্জস্য করুন!

শ .. এটা একটা গোপন কথা !!

স্পষ্টতই এটি করতে হবে /proc/sys/net/ipv4/route/secret_intervalযা 600 এ ডিফল্ট এবং রুট ক্যাশে পর্যায়ক্রমে ফ্লাশিং নিয়ন্ত্রণ করে

secret_intervalকার্নেল কত ঘন ঘন দূরে সমস্ত রুট হ্যাশ এন্ট্রি কিভাবে নতুন / পুরাতন তারা নির্বিশেষে উড়িয়ে দেওয়ার নির্দেশ দেয়। আমাদের পরিবেশে এটি সাধারণত খারাপ। সিপিইউ প্রতিবার ক্যাশে সাফ হওয়ার পরে প্রতি সেকেন্ডে কয়েক হাজার এন্ট্রি পুনর্নির্মাণে ব্যস্ত থাকবে। তবে আমরা এটিকে দিনে একবার চালানোর জন্য সেট করে রেখেছি স্মৃতি ফাঁসকে উপসাগরীয় স্থানে রাখতে (যদিও আমাদের কখনও তা হয়নি)।

আমরা এটি হ্রাস করতে পেরে খুশি হলেও, রুট ক্যাশে থেকে পুরানো মানগুলি কেবলমাত্র দ্রুত ঠেলে না দেওয়ার পরিবর্তে নিয়মিত বিরতিতে পুরো রুট ক্যাশে ফেলে দেওয়ার পরামর্শ দেওয়া অদ্ভুত বলে মনে হয়

কিছু তদন্তের পরে, আমরা দেখতে পেলাম /proc/sys/net/ipv4/route/gc_elasticityযেটি রুটের টেবিলের আকারটি পরীক্ষা করে রাখার জন্য একটি ভাল বিকল্প বলে মনে হচ্ছে:

gc_elasticityরুট হ্যাশ এন্ট্রিগুলির মেয়াদ শেষ হওয়ার আগে কার্নেলটি গড় বালতি গভীরতার হিসাবে সর্বোত্তমভাবে বর্ণনা করা যেতে পারে। এটি সক্রিয় রুটের উপরের সীমাটি বজায় রাখতে সহায়তা করবে।

রুট ক্যাশে আরও আগ্রাসীভাবে ছাঁটাইয়ের আশায় আমরা 8 থেকে 4 এ স্থিতিস্থাপকতাটি সামঞ্জস্য করেছি। secret_intervalআমাদের কাছে সঠিক মনে হয় না। তবে এখানে বেশ কয়েকটি সেটিংস রয়েছে এবং এটি অস্পষ্ট যা আসলে এখানে যাওয়ার সঠিক উপায়।

  • / প্রোক / সিএস / নেট / আইপিভি 4 / রুট / জিসি_এলাস্টিকটি (8)
  • / ক্রোক / সিস / নেট / আইপিভি 4 / রুট / জিসি_ইন্টারভাল (60)
  • / ক্রোক / সিস / নেট / আইপিভি 4 / রুট / জিসি_মিনি_ইন্টারভাল (0)
  • / ক্রোক / সিস / নেট / আইপিভি 4 / রুট / জিসি_টাইমআউট (300)
  • / ক্রোক / সিস / নেট / আইপিভি 4 / রুট / সিক্রেট_ইন্টারওয়াল (600)
  • / proc / sys / নেট / ipv4 / রুট / জিসি_থ্রেশ (?)
  • rhash_entries (কার্নেল প্যারামিটার, ডিফল্ট অজানা?)

আমরা লিনাক্সের রাউটিংকে আরও খারাপ করতে চাই না , সুতরাং আমরা এই ধরনের কিছু সেটিংস নিয়ে গণ্ডগল করতে ভয় পাচ্ছি।

হাই ট্র্যাফিক HAProxy দৃষ্টান্তের জন্য, কেউ কী রাউটিং পরামিতিগুলির সাথে টিউন করতে সবচেয়ে ভাল পরামর্শ দিতে পারে?

উত্তর:


28

আমি কখনই এই সমস্যার মুখোমুখি হই নি। তবে আপনার হ্যাশ টেবিলের প্রস্থটি এর গভীরতা হ্রাস করার জন্য আপনাকে সম্ভবত বাড়ানো উচিত। "Dmesg" ব্যবহার করে আপনি দেখতে পাবেন যে আপনার বর্তমানে কতগুলি এন্ট্রি রয়েছে:

$ dmesg | grep '^IP route'
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

কার্নেল বুট কমান্ড লাইন প্যারামিটারের সাহায্যে আপনি এই মানটি পরিবর্তন করতে পারেন rhash_entries। প্রথমে হাত দিয়ে চেষ্টা করে দেখুন এটি আপনার lilo.confবা যুক্ত করুন grub.conf

উদাহরণ স্বরূপ: kernel vmlinux rhash_entries=131072

এটি সম্ভবত আপনার একটি সীমিত হ্যাশ টেবিল রয়েছে কারণ আপনি আপনার HAProxy VM- তে সামান্য মেমরি নির্ধারণ করেছেন (রুটের হ্যাশের আকারটি মোট র‌্যামের উপর নির্ভর করে সামঞ্জস্য করা হয়েছে)।

সম্পর্কিত tcp_mem, সাবধান। আপনার প্রাথমিক সেটিংস আমাকে ভাবায় যে আপনি 1 জিবি র‌্যাম নিয়ে চলেছেন, যার মধ্যে 1/3 টিসিপি সকেটে বরাদ্দ করা যেতে পারে। এখন আপনি টিসিপি সকেটে 367872 * 4096 বাইট = 1.5 গিগাবাইট র‌্যাম বরাদ্দ করেছেন। স্মৃতিশক্তি শেষ না হওয়ার জন্য আপনার খুব সতর্ক হওয়া উচিত। থাম্বের একটি নিয়ম হ্যাপ্রোক্সিকে মেমরির 1/3 অংশ এবং টিসিপি স্ট্যাকের জন্য আরও 1/3 এবং সিস্টেমের বাকী 1/3 অংশ বরাদ্দ করা হয়।

আমি সন্দেহ করি যে আপনার "সকেট মেমরির বাইরে" বার্তাটি ডিফল্ট সেটিংস থেকে tcp_rmemএবং থেকে আসে tcp_wmem। ডিফল্টরূপে আপনার প্রতিটি সকেটের আউটপুটটিতে 64 কেবি এবং ইনপুটটিতে 87 কেবি বরাদ্দ রয়েছে। এটি কেবলমাত্র সকেট বাফারদের জন্য প্রক্সাইড সংযোগের জন্য মোট 300 কেবি এর অর্থ। HAProxy এর জন্য 16 বা 32 কেবি যোগ করুন এবং আপনি দেখতে পাচ্ছেন যে 1 গিগাবাইট র‌্যামের সাহায্যে আপনি কেবল 3000 সংযোগগুলি সমর্থন করবেন।

tcp_rmemএবং tcp_wmem(মিডল প্যারাম) এর ডিফল্ট সেটিংস পরিবর্তন করে আপনি মেমরিতে অনেক কম পেতে পারেন। আমি লেখার বাফারের জন্য কম 4096 এবং 73৩০০ বা 16060 tcp_rmem(5 বা 11 টিসিপি বিভাগ) এর মান সহ ভাল ফলাফল পেয়েছি । পুনরায় আরম্ভ না করে আপনি এই সেটিংস পরিবর্তন করতে পারেন তবে সেগুলি কেবলমাত্র নতুন সংযোগে প্রযোজ্য হবে।

আপনি যদি আপনার সিস্টেমে খুব বেশি স্পর্শ না করা পছন্দ করেন তবে সর্বশেষতম HAProxy, 1.4-dev8 আপনাকে গ্লোবাল কনফিগারেশন এবং প্রতিপাশে (ক্লায়েন্ট বা সার্ভার) থেকে এই পরামিতিগুলিকে টুইঙ্ক করতে দেয়।

আমি আশা করি এটি সাহায্য করে!


8

Out of socket memory errorপ্রায়ই বিভ্রান্তিকর করা হয়। বেশিরভাগ সময়, ইন্টারনেটের মুখোমুখি সার্ভারগুলিতে, এটি মেমরির বাইরে চলে যাওয়ার সাথে সম্পর্কিত কোনও সমস্যা নির্দেশ করে না । আমি যেমন কোনও ব্লগ পোস্টে আরও বৃহত্তর বিবরণে ব্যাখ্যা করেছি , সর্বাধিক সাধারণ কারণ এতিম সকেটের সংখ্যা। এতিম সকেট এমন একটি সকেট যা কোনও ফাইল বর্ণনাকারীর সাথে সম্পর্কিত নয়। নির্দিষ্ট পরিস্থিতিতে, Out of socket memory errorসীমাটি ( /proc/sys/net/ipv4/tcp_max_orphans) থেকে আপনি 2x বা 4x দূরে থাকা সত্ত্বেও কার্নেলটি ইস্যু করবে । এটি ইন্টারনেট-মুখোমুখি পরিষেবাগুলিতে প্রায়শই ঘটে এবং একেবারে স্বাভাবিক। এক্ষেত্রে সঠিক ক্রিয়াটি হ'ল tcp_max_orphansআপনার চূড়ান্ত ট্র্যাফিকের মাধ্যমে আপনি সাধারণত এতিমদের সংখ্যা কমপক্ষে 4x দেখতে পারেন।

কোন পরামর্শ যে টিউনিং বিশেষ পরামর্শ দেওয়া হচ্ছে কথা শুনো না tcp_memবা tcp_rmemবা tcp_wmem, যদি না আপনি সত্যিই জানি তুমি কি করছেন। যারা এই পরামর্শগুলি দিচ্ছেন তারা সাধারণত তা করেন না। তাদের ভোডো প্রায়শই আপনার পরিবেশের জন্য ভুল বা অনুপযুক্ত এবং আপনার সমস্যার সমাধান করবে না। এটি আরও খারাপ করতে পারে।


1
যখন এটি হয়, বার্তাটি ডেমসগে আলাদা হয়, আপনি "অনেক অনাথ সকেট" দেখতে পাবেন। তবে আমি আপনার সাথে একমত যে এতিমরা প্রচুর পরিমাণে স্মৃতি গ্রহণ করতে পারে।
উইলি তারেরউ

আপনি যখন সংখ্যাটি ছাড়িয়ে /proc/sys/net/ipv4/tcp_max_orphansযাবেন তখন একটি ভিন্ন ত্রুটি অনুভব করবেন। উদাহরণস্বরূপ পুরো স্ট্যাক এক্সচেঞ্জ স্ট্যাকটি /proc/sys/net/ipv4/tcp_max_orphans65536 এ রয়েছে এবং /proc/net/sockstatটিসিপি ফলাফল: 2996 অনাথ 171 টি 15972 বরাদ্দ 2998 মেম 1621 - এমন একটি পার্থক্য যা উপেক্ষা করা যায় না।
জিওফ ডালগাস

-4

আমরা নিয়মিত এই পরামিতিগুলির কয়েকটি টিউন করি। উচ্চ থ্রুপুট, কম বিলম্বিত ট্রেডিং প্ল্যাটফর্মগুলির জন্য আমাদের মানটি হ'ল:

নেট.ipv4.tcp_rmem = 4096 16777216 33554432
নেট.ipv4.tcp_wmem = 4096 16777216 33554432
নেট.ipv4.tcp_mem = 4096 16777216 33554432
নেট.core.rmem_default = 16777216
নেট.core.wmem_default = 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
নেট.core.netdev_max_backlog = 30000
নেট.core.netdev_max_backlog = 30000

1
উইলির গণিতে প্রতি আপনার স্ট্যান্ডার্ড মেমরির চাপ # (মাঝের সংখ্যা) 68 জিবি ?! তিনবার (rmem, wmem, meme) ??
জেফ আতউড

10
এই টিউনেবলগুলি ভুল এবং খুব ঘন ঘন বেঞ্চ পরিবেশে পাওয়া যায় অন্ধভাবে অনুলিপি করে অনুলিপি করা। মাত্র কয়েকটি সাম্প্রতিক অধিবেশনগুলির সাথে তাদের কোনও সমস্যা হবে না, তবে 100 টিসিপি সকেটের সাথেও আপনি ৩.২ গিগাবাইট র‌্যাম বরাদ্দ করবেন। যতক্ষণ লেটেন্সি কম থাকবে ততক্ষণ আপনি সন্দেহজনক কিছু লক্ষ্য করবেন না। আউটপুট বাফারগুলি পূরণ করতে, বা কোনও স্থানীয় কার্য স্থির করতে এবং ইনপুট বাফার ফিল দেখতে আপনাকে কেবল স্থানান্তরকালে একটি রিমোট মেশিনটি প্লাগ করতে হবে। এটি উন্মাদ ...
উইলি তারেরু

6
জেফ, এটি তিনবার নয়। tcp_mem পৃষ্ঠাগুলিতে রয়েছে এবং বিশ্ব আকারের সংজ্ঞা দেয়। tcp_rmem এবং tcp_wmem বাইটে থাকে এবং প্রতি সকেটের আকার নির্ধারণ করে।
উইলি তারেরু

এই টিউনিয়েবলগুলি ভুল দেখায়, ছোট ডেটা সহ সাম্প্রতিক সার্ভারগুলির জন্য আপনি এত বেশি সকেট বাফার সংরক্ষণ করতে চান না এবং tcp_mem r / wmem থেকে সম্পূর্ণ আলাদা, একই সংখ্যাগুলি ব্যবহার করা আসলেই বোধগম্য নয়, (একটি সংযোগ প্রতি বাইট হয় অন্যটিতে সিস্টেম প্রতি পৃষ্ঠাগুলি)
e ই
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.