You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
من شاید چند هفته با این مشکل درگیر بودم که گفتم تجربم رو باهاتون به اشتراک بگذارم.
من با CentOS 7.9 کار میکنم. وقتی تعداد کاربرام زیاد میشد، اتصالات کلاینت کاربر قطعیهای زیادی پیدا میکرد و در سمت لاگ x-ui که البته اشاره به xray داره مرتب خطاهای "too many open files" ظاهر میشد.
بعد از تحقیق زیاد و تست کردن راهحلهای مختلف مشکل رو در تنظیم همین پارامتر nofile دیدم.
فقط برای اصلاحش روش تنظیم در فایل /etc/security/limits.conf که شما گذاشتید و منم در زیر دوباره میزارم، کافی نیست(شاید حتی در مواردی بیتأثیر باشه) ولی به هر حال بی ضرر هست انجامش:
برای تست عدم تاثیر پذیریش هم با اجرای این دستور میشد چک کرد که پروسه مربوط به فایل xray-linux-amd64 مقدار درست رو نگرفته:
cat /proc/`pidof xray-linux-amd64`/limits
در نهایت به این مقاله رسیدم: https://woshub.com/too-many-open-files-error-linux/
In Linux, you can configure max open files limits at several levels:
OS kernel
Service
User
ظاهراً تغییر این پارامتر امنیتی در سه سطح کرنل، سرویس و یوزر صورت میگیره.
دستورات قبلی در سطح کرنل و یوزر عمل میکردند. که حتی اگر xray رو تحت خط فرمان دستی اجرا میکردیم، nofile روی پروسهی مربوطه تأثیرشو گذاشته بود و اوکی بود.
اما مشکل وقتی بود که ما در پنل x-ui فایل xray رو در سطح سرویس اجرا میکنیم.
برای اینکه سرویس هم تأثیر خودشو بگیره در فایل سرویس x-ui:
(شاید تنها دو خط آخر مربوط به موضوعه و کافی باشه، سایر دستورات رو جایی دیدم که خیلی کاربردشون رو بررسی نکردم و فکر کردم مفیدن و توی داکیومنتم بودن دیگه گذاشتم باشن)
و بعدم ریستارت سرویسها:
systemctl daemon-reload
systemctl restart x-ui
درنهایت هم چک میکنیم:
cat /proc/`pidof xray-linux-amd64`/limits
Max processes 100000 100000 processes
Max open files 1048576 1048576 files
در ضمن شما در مستندات از عدد 51200 استفاده کرده بودید که کمه و من در نمونههای بالام از ماکزیمم مقدار 1048576 استفاده کردم.
اینطوری بود که مشکل من حل شد، گفتم به اشتراک بگذارم شاید خواستید توی ریپو اضافه کنید(کنم).
تشکر
نبی
The text was updated successfully, but these errors were encountered:
سلام،
در اینجا:
https://github.com/rahgozar94725/freedom/blob/main/domestic-server/server-setup.md#%D8%A8%D9%87%DB%8C%D9%86%D9%87%D8%B3%D8%A7%D8%B2%DB%8C-%D8%B3%D8%B1%D9%88%D8%B1
دیدم صحبت از تنظیم nofile کردید.
من شاید چند هفته با این مشکل درگیر بودم که گفتم تجربم رو باهاتون به اشتراک بگذارم.
من با CentOS 7.9 کار میکنم. وقتی تعداد کاربرام زیاد میشد، اتصالات کلاینت کاربر قطعیهای زیادی پیدا میکرد و در سمت لاگ x-ui که البته اشاره به xray داره مرتب خطاهای "too many open files" ظاهر میشد.
بعد از تحقیق زیاد و تست کردن راهحلهای مختلف مشکل رو در تنظیم همین پارامتر nofile دیدم.
فقط برای اصلاحش روش تنظیم در فایل /etc/security/limits.conf که شما گذاشتید و منم در زیر دوباره میزارم، کافی نیست(شاید حتی در مواردی بیتأثیر باشه) ولی به هر حال بی ضرر هست انجامش:
برای تست عدم تاثیر پذیریش هم با اجرای این دستور میشد چک کرد که پروسه مربوط به فایل xray-linux-amd64 مقدار درست رو نگرفته:
در نهایت به این مقاله رسیدم:
https://woshub.com/too-many-open-files-error-linux/
In Linux, you can configure max open files limits at several levels:
OS kernel
Service
User
ظاهراً تغییر این پارامتر امنیتی در سه سطح کرنل، سرویس و یوزر صورت میگیره.
دستورات قبلی در سطح کرنل و یوزر عمل میکردند. که حتی اگر xray رو تحت خط فرمان دستی اجرا میکردیم، nofile روی پروسهی مربوطه تأثیرشو گذاشته بود و اوکی بود.
اما مشکل وقتی بود که ما در پنل x-ui فایل xray رو در سطح سرویس اجرا میکنیم.
برای اینکه سرویس هم تأثیر خودشو بگیره در فایل سرویس x-ui:
بعد از [Service] این دستورات رو میزنیم:
(شاید تنها دو خط آخر مربوط به موضوعه و کافی باشه، سایر دستورات رو جایی دیدم که خیلی کاربردشون رو بررسی نکردم و فکر کردم مفیدن و توی داکیومنتم بودن دیگه گذاشتم باشن)
و بعدم ریستارت سرویسها:
درنهایت هم چک میکنیم:
در ضمن شما در مستندات از عدد 51200 استفاده کرده بودید که کمه و من در نمونههای بالام از ماکزیمم مقدار 1048576 استفاده کردم.
اینطوری بود که مشکل من حل شد، گفتم به اشتراک بگذارم شاید خواستید توی ریپو اضافه کنید(کنم).
تشکر
نبی
The text was updated successfully, but these errors were encountered: