یک دیباگ جالبی که من اخیرا داشتم، پیرو مسئلهی کندی push کردن در یک رجیستری توسط رانر بود.
مسئله اینه که یک رانر سلف هاستد در خارج از کشور در یکی از دیتاسنترها قرار دارد که زمانی که این رانر شروع به کار میکند و اجرا میشود، برای پوش کردن در رجیستری بسیار کند است. به شکلی که یک ایمیج چند صد مگ، حدود نیم الی یک ساعت طول میکشد تا در رجیستری پوش شود. رجیستری در ایران قرار دارد FYI. موارد مختلفی در این زمینه چک شدن اما خیلی راه تمیزی هم برای دیباگ وجود نداره. mtrای که از رانر تا سرور رجیستری گرفته میشه سالمه و عملا هیچ پکت لاسی اتفاق نمیوفته. پس خب مشکل از چیه؟
عملا خیلی راههای سادهای برای فهمیدن دلیل این موارد نیست. از اونجایی که سطح فیلترینگ هم خیلی زیاد هست و زیاد دستکاری شده، نمیشه دقیق متوجه شد مشکل از چیه یا اگر فهمیدیم هم، کاری بتونیم بکنیم که اوکی شه همهچی.
مثلا یک مسئلهی دیگری که بود این بود که از داخل داشتیم یه چیزی به خارج پوش میکردیم و خب کند بود. و خب دلیلش مشخص بود، اون پاپ سایتی از کلاد فلر که نزدیک ایران بود واقعا داشت اذیت میکرد و کاملا همهچیز کند بود و نمیشد کاریش کرد.
حالا موردی که اینجا حدس زدیم و هندل هم کرد، mtu بود. مفهوم mtu یا maximum transmission unit میگه که بزرگترین و بیشترین سایزی که دیتای یه پکت بتونه داشته باشه که بفرسته بره چقدره. عملا وقتی این ست میشه، میتونه مفاهیم fragmentation هم پیش بیاد.
بحث چی بود؟ بحث اینه که زمانی که از رانر یه چیزی به سمت رجیستری که میخواست بیاد، باید از چندین تا hop عبور میکرد. هر کدوم از این hopها میتونن مقادیر متفاوتی رو تنظیم کرده باشن برای mtu. و bottleneck این وسط دقیقا همینه. یعنی ممکنه یکی از hopهای این وسط تنظیم کرده باشه که mtuش مثلا ۲۰۰۰ باشه و یکی دیگه زده باشه که 1500 باشه. (دیفالت عموما ۱۵۰۰ هست) و خب کمترین مقداری که یکی از hopها تنظیم کرده باشه mtuشو، عملا باعث میشه ما به مشکل بخوریم. چرا؟ چون مثلا ما توی رانرمون تنظیم کردیم که mtuش باشه ۲۶۰۰ و یکی از اون hopهایی که اون وسط قرار داره و ما داریم پکتمون رو ازش رد میکنیم، ممکنه مثلا باشه ۱۴۰۰. خب این عملا باعث میشه وقتی که پکت ما میرسه دست این hop، این مجبوره که بیاد fragmentش کنه و بشکنه به دوتا پکت و بعدش هدر بزنه و مجدد بفرسته بره. این پراسسهایی که این hop وسط مسیر جهت باز کردن و fragment کردن و بستن مجدد قراره بده، باعث کندی خیلی محسوسی میشه.
کاری که ما کردیم این بود که mtu رانر رو (به صورت آزمون و خطا) هی دست کاری میکردیم و کم و زیاد میکردیم تا ببینیم آیا مسئله رفع میشه یا نه. طبیعتا ما اطلاعاتی هم راجعبه hopهای این وسط راه نداریم که هرکدوم چقدر هست میزان mtuشون. موردی که بود، اینه که ممکنه این hopها حتی عوض شن و ثابت نیستن. لذا با ما سعی کردیم هی کم و زیاد کنیم و تست کنیم و در نهایت یک مقداری گذاشتیم که وقتی تنظیم شد، به راحتی ایمیج پوش میشد بدون حس شدن هیچ کندیای.
مسئله اینه که یک رانر سلف هاستد در خارج از کشور در یکی از دیتاسنترها قرار دارد که زمانی که این رانر شروع به کار میکند و اجرا میشود، برای پوش کردن در رجیستری بسیار کند است. به شکلی که یک ایمیج چند صد مگ، حدود نیم الی یک ساعت طول میکشد تا در رجیستری پوش شود. رجیستری در ایران قرار دارد FYI. موارد مختلفی در این زمینه چک شدن اما خیلی راه تمیزی هم برای دیباگ وجود نداره. mtrای که از رانر تا سرور رجیستری گرفته میشه سالمه و عملا هیچ پکت لاسی اتفاق نمیوفته. پس خب مشکل از چیه؟
عملا خیلی راههای سادهای برای فهمیدن دلیل این موارد نیست. از اونجایی که سطح فیلترینگ هم خیلی زیاد هست و زیاد دستکاری شده، نمیشه دقیق متوجه شد مشکل از چیه یا اگر فهمیدیم هم، کاری بتونیم بکنیم که اوکی شه همهچی.
مثلا یک مسئلهی دیگری که بود این بود که از داخل داشتیم یه چیزی به خارج پوش میکردیم و خب کند بود. و خب دلیلش مشخص بود، اون پاپ سایتی از کلاد فلر که نزدیک ایران بود واقعا داشت اذیت میکرد و کاملا همهچیز کند بود و نمیشد کاریش کرد.
حالا موردی که اینجا حدس زدیم و هندل هم کرد، mtu بود. مفهوم mtu یا maximum transmission unit میگه که بزرگترین و بیشترین سایزی که دیتای یه پکت بتونه داشته باشه که بفرسته بره چقدره. عملا وقتی این ست میشه، میتونه مفاهیم fragmentation هم پیش بیاد.
بحث چی بود؟ بحث اینه که زمانی که از رانر یه چیزی به سمت رجیستری که میخواست بیاد، باید از چندین تا hop عبور میکرد. هر کدوم از این hopها میتونن مقادیر متفاوتی رو تنظیم کرده باشن برای mtu. و bottleneck این وسط دقیقا همینه. یعنی ممکنه یکی از hopهای این وسط تنظیم کرده باشه که mtuش مثلا ۲۰۰۰ باشه و یکی دیگه زده باشه که 1500 باشه. (دیفالت عموما ۱۵۰۰ هست) و خب کمترین مقداری که یکی از hopها تنظیم کرده باشه mtuشو، عملا باعث میشه ما به مشکل بخوریم. چرا؟ چون مثلا ما توی رانرمون تنظیم کردیم که mtuش باشه ۲۶۰۰ و یکی از اون hopهایی که اون وسط قرار داره و ما داریم پکتمون رو ازش رد میکنیم، ممکنه مثلا باشه ۱۴۰۰. خب این عملا باعث میشه وقتی که پکت ما میرسه دست این hop، این مجبوره که بیاد fragmentش کنه و بشکنه به دوتا پکت و بعدش هدر بزنه و مجدد بفرسته بره. این پراسسهایی که این hop وسط مسیر جهت باز کردن و fragment کردن و بستن مجدد قراره بده، باعث کندی خیلی محسوسی میشه.
کاری که ما کردیم این بود که mtu رانر رو (به صورت آزمون و خطا) هی دست کاری میکردیم و کم و زیاد میکردیم تا ببینیم آیا مسئله رفع میشه یا نه. طبیعتا ما اطلاعاتی هم راجعبه hopهای این وسط راه نداریم که هرکدوم چقدر هست میزان mtuشون. موردی که بود، اینه که ممکنه این hopها حتی عوض شن و ثابت نیستن. لذا با ما سعی کردیم هی کم و زیاد کنیم و تست کنیم و در نهایت یک مقداری گذاشتیم که وقتی تنظیم شد، به راحتی ایمیج پوش میشد بدون حس شدن هیچ کندیای.
🔥11❤1👍1
منتهی یه چیزی هم من این وسط یاد گرفتم خیلی جالب بود. شبکه خب چندینتا لایه داره و یه سری پروتکل که در سطح لایه applocation قرار دارن، از طرفی دیتا رو هم (که میشه تا حد خوبی بیشترین میزان دیتای packet) تولید میکنن. عملا ما باید بتونیم توی خود این پروتکلها تنظیم کنیم که چه مقدار دیتا تولید کنه که پکتها به مشکل fragmentation نخورن که درنهایت همون پکتی تولید میشه فرستاده شه بره از تمامی hopها. ولی خب، خیلی از پروتکلهای لایه آخر این رو هندل نمیکنن. به همین دلیل میتونیم توی خود interface شبکه نیز بزنیم که میزان mtu چقدر باشه.
مثلا شما اگر دستور
مثلا شما اگر دستور
ifconfig رو بزنید کف ترمینالتون، وقتی که interfaceها رو بهتون نشون میده، حالا مثلا eth0 باشه یا eno اینها باشه یا هرچی، اونجا نوشته که mtuای که برای این interface تنظیم شده چقدره. این دقیقه به این دلیله که شاید ما نتونیم توی پروتکلهای لایهی آخر تنظیم کنیم که چقدر باشه mtuش ولی خب میتونیم بریم توی interface شبکه و تنظیم کنیم که این پکتها رو بکنه فلان قدر سایز و بعد بفرسته که بره.👍7
ولی خب به طور خاص کار ما با داکر بود، که خودش داشت. میشه توی daemon داکر رفت و تنظیم کرد که میزانی که برای mtu نیاز داره چقدر باشه تا خودش مقادیر دیتایی که نیاز هست تولید کنه و بذاره رو حواسش باشه.
البته این هست، ولی یه چیز دیگه هم هست. یعنی من دقیقا نمیدونم که آیا داکر اینقدر دیتا تولید میکنه، یا که نه. چون که زمانی که شما با داکر کار کنید، یک interface با نام docker0 هم ساخته میشه که ممکنه از اون interface بفرسته اصلا که خب یعنی در عمل بازم در سطح interface تعیین شده.
البته این هست، ولی یه چیز دیگه هم هست. یعنی من دقیقا نمیدونم که آیا داکر اینقدر دیتا تولید میکنه، یا که نه. چون که زمانی که شما با داکر کار کنید، یک interface با نام docker0 هم ساخته میشه که ممکنه از اون interface بفرسته اصلا که خب یعنی در عمل بازم در سطح interface تعیین شده.
👍8
بعد میخواستم سیس بیام که خودم بلدم مسیر رو و نیاز نیست به مسیریاب.
🤣27🔥3🤡1
دیگه الان بگن مثلا ثروت ایلان ماسک ۲میلیارد دلاره متوجه میشیم راحت چند تومانه.
👍15🤣1