رشد دیسک سرور VPN از کجا می‌آید و چگونه آن را محدود کنیم
رشد گزارش‌ها، inode تغییرنام‌یافته و journal بدون سقف همه به شکل یک دیسک پر دیده می‌شوند. نرخ را اندازه بگیرید، نویسنده را محدود کنید و سقف را پس از راه‌اندازی دوباره بررسی کنید.
تونل دیگر اتصال نمی‌پذیرد، سرویس دو بار دوباره راه‌اندازی می‌شود و پس از آن هیچ چیز در گزارش آن دیده نمی‌شود. همان سکوت سرنخ است، زیرا چیزی که دیسک را پر کرده گزارش است و برنامهٔ پس‌زمینه جایی برای نوشتن خطایی که منتظرش هستید ندارد. هر سرویس دیرینه می‌تواند به این وضعیت برسد و حذف شاخه‌ای به نام logs به‌ندرت آن را درست می‌کند. راه‌حل پایدار این است که بدانید کدام انبار رشد کرده، سیاست نگهداری آن در دست کیست و آیا نویسنده واقعاً فضا را رها کرده است.
انباری را که رشد کرده و نرخی را که با آن رشد کرده بیابید
با دو عدد که آسان فراموش می‌شوند شروع کنید: بلوک‌های آزاد و inodeهای آزاد. یک سامانهٔ پرونده می‌تواند فضای فراوان گزارش کند و باز هم نوشتن را رد کند، چون inodeای باقی نمانده است، و این زمانی رخ می‌دهد که سرویس برای هر نشست یک پرونده می‌سازد. هر دو خوانش را روی همان والیوم بخواهید، چون پاسخ‌ها می‌توانند همان بعدازظهر با هم ناسازگار باشند. این کار را وقتی میزبان سالم است انجام دهید تا اعداد کار عادی را توصیف کنند، نه یک قطعی.
df -h /var
df -i /varسپس رشد را به یک مالک نسبت دهید. رقم مصرف خودِ journal فقط خودش را پوشش می‌دهد و هرگز برنامهٔ پس‌زمینه‌ای را نمی‌بیند که به مسیری از پروندهٔ پیکربندی‌اش می‌نویسد.
journalctl --disk-usageرشد در طول زمان بیش از هر خوانش تک‌باره می‌گوید. سطح اشکال‌زدایی که روشن رها شده، حلقهٔ تلاش دوباره‌ای که هر کوشش را ثبت می‌کند، یا پروندهٔ ضبطی که هیچ‌کس متوقفش نکرده: هر یک می‌تواند در یک لحظه عادی و یک ساعت بعد نگران‌کننده به نظر برسد. یک خوانش بگیرید، از یک دورهٔ شلوغ بگذرید، خوانش دیگری بگیرید و بر فاصله تقسیم کنید. نرخی که می‌توانید بیان کنید، ظرفیت را به تصمیم تبدیل می‌کند نه به آتش‌سوزی.
چرخش با پروندهٔ باز چه می‌کند
پروندهٔ گزارش نامی است که به یک inode اشاره می‌کند، و فضا تنها وقتی بازمی‌گردد که آخرین دستهٔ باز بسته شود. پرونده را تغییر نام دهید و نویسنده همان inode را پر می‌کند؛ حذفش کنید و نویسنده inodeای بی‌نام را پر می‌کند. همین وضعیت توضیح می‌دهد که چرا جملهٔ «پرونده را حذف کردم و دیسک پر ماند» توصیف‌گرهای پرونده را می‌گوید، نه سامانهٔ پروندهٔ خراب را. راه‌اندازی دوبارهٔ نویسنده، یا برگزیدن شیوهٔ چرخشی که پرونده را باز می‌کند، همان چیزی است که بلوک‌ها را واقعاً برمی‌گرداند.
lsof +L1 | headسیاست متعلق به جزئی است که پرونده را می‌نویسد. journal محدودیت‌های انبار خود را از پروندهٔ پیکربندی‌اش اعمال می‌کند، در حالی که سرویس مبتنی بر پرونده معمولاً به logrotate تکیه می‌کند، یا با قاعدهٔ ساخت به‌همراه نشانهٔ بازگشایی، یا با شیوهٔ کوتاه‌سازی درجا هنگامی که نویسنده نمی‌تواند دوباره باز کند. نخست تصمیم را بدون تغییر چیزی تأیید کنید:
logrotate -d /etc/logrotate.confسقف کجا باید باشد و چه اندازه باید داشته باشد
سقف را آنجا بگذارید که نویسنده پیکربندی شده، نه در نقطهٔ اتصال. سهمیه روی کل والیوم میزبان را حفظ می‌کند اما نمی‌گوید کدام سرویس اول می‌افتد، و اسکریپت پاک‌سازی سراسری تمایل دارد شواهدی را پاک کند که رخداد بعدی لازم دارد. سقف journal، شمار چرخش با اندازهٔ بیشینه و نگهداری در سطح برنامه هر یک یک تولیدکننده را محدود می‌کنند. با هم کل را محدود می‌کنند؛ به‌تنهایی هر یک گمانه‌ای است.
این سقف را از نگهداری‌ای که می‌توانید از آن دفاع کنید اندازه بگیرید، نه از فضای آزاد موجود. اگر بازبینی به یک هفته کوشش اتصال نیاز دارد، journal باید یک هفته را با شلوغ‌ترین نرخ پیش‌بینی‌شده نگه دارد، و آن نرخ همان عددی است که پیش‌تر اندازه گرفته شده.
گزارش اشکال‌زدایی شیوه‌ای موقت با زمان آغاز ثبت‌شده است، نه برنامهٔ انبار. پرسش حریم خصوصی را در همان تصمیم نگه دارید، چون گزارش‌های اتصال نشانی‌ها و شناسه‌ها را حمل می‌کنند. نگهداری طولانی‌تر هم گزینهٔ پردازش داده است و باید کسی آن را بگیرد که هر دو محدودیت را می‌شناسد.
سقف را پس از راه‌اندازی دوباره بررسی کنید
تغییری در نگهداری که تا راه‌اندازی دوبارهٔ بعدی می‌ماند، تغییر نیست. نویسنده را دوباره راه‌اندازی کنید، تأیید کنید که محدودیت تازه اعمال می‌شود و بررسی کنید که چرخش پس از آن هنوز اجرا می‌شود. برای journal، یک راه‌اندازی دوباره و یک خوانش مصرف به هر دو پرسش پاسخ می‌دهد:
systemctl restart systemd-journald
journalctl --disk-usageبرای سرویس مبتنی بر پرونده، کار چرخش را یک بار دستی اجرا کنید و تأیید کنید که پرونده جایگزین و توصیف‌گر دوباره باز شده است. نویسنده‌ای که دستهٔ کهنه را نگه می‌دارد از یک بررسی سطحی می‌گذرد و بار بعد که والیوم پر شود شکست می‌خورد. در طول آزمون فضای آزاد را بپایید، چون پرونده‌ای که کوچک شد و فضا برنگشت یعنی inode کهنه هنوز نگه داشته شده است.
خوانش بعدی را با این یکی بسنجید
یک هفته بعد برگردید و نرخ رشد را با نرخ ثبت‌شده بسنجید. نرخ همخوان یعنی سقف می‌گیرد و بار کاری پایدار است؛ نرخ دوبرابر یعنی چیزی تغییر کرده و پرسش سودمند این است که چه. نخست محتوای گزارش را برای شکست‌های تکرارشونده بخوانید، چون حلقهٔ تلاش دوباره هم نشانه است و هم علت حجم. سپس هر چیز تازه فعال‌شده را بررسی کنید، از جمله سطوح اشکال‌زدایی که در جریان یک رخداد روشن شده و هرگز خاموش نشده‌اند.
پشتیبان‌ها را بیرون از همان والیوم نگه دارید، یا بپذیرید که یک دیسک پر پشتیبان را هم با خود می‌برد. نسخه‌ای که روی همان میزبانی نوشته شود که از آن محافظت می‌کند، برنامهٔ بازیابی نیست، و نگهداری آن پاسخ خودش را می‌خواهد.
بنویسید چه چیزی، کجا، چه مدت نگه داشته می‌شود و چه کسی آن را برمی‌دارد. همان جمله تحویل‌دادنی است، و تنها بخشی از این کار است که از راه‌اندازی دوبارهٔ بعدی جان سالم به در می‌برد.