Database Labdon
797 subscribers
33 photos
2 videos
1 file
727 links
🕸 Database Academy

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
here's a quirk to be aware of

🟢 خلاصه مقاله:
قبل از ارتقا به Debian 13 یک نکته ریز اما مهم را در نظر بگیرید: عمده‌ترین دردسر معمولاً از مخازن خارجی APT می‌آید. وقتی منابع از bookworm به trixie تغییر کنند، ممکن است برخی مخازن فروشندگان (مثل Docker، Grafana، NodeSource، GitLab یا VS Code) هنوز شاخه trixie نداشته باشند؛ نتیجه‌اش خطاهای APT، نگه‌داشتن بسته‌ها یا تلاش برای حذف بسته‌های متا برای حل وابستگی‌هاست. راه امن این است که این مخازن را موقتاً در /etc/apt/sources.list.d/ غیرفعال کنید، ارتقا را کامل کنید و بعد وقتی پشتیبانی trixie اضافه شد دوباره فعالشان کنید (یا اگر امکان دارد آن‌ها را روی شاخه stable بگذارید). همچنین وضعیت بسته‌های hold (با apt-mark showhold) و پین‌ها (با apt policy) را بررسی کنید تا مانع حل تمیز وابستگی‌ها نشوند. شبیه‌سازی ارتقا با apt-get dist-upgrade -s به شما می‌گوید چه چیزی قرار است تغییر کند. اگر به firmware نیاز دارید، مطمئن شوید اجزای لازم (از جمله non-free-firmware در صورت نیاز) در منابع باقی می‌مانند. هنگام پرسش‌های APT درباره جایگزینی فایل‌های پیکربندی هم تغییرات را دقیق بررسی کنید تا تنظیمات سفارشی شما از بین نرود. خلاصه: پشتیبان بگیرید، فضای دیسک را چک کنید، مخازن ثالث را موقتاً غیرفعال کنید، Release Notes مربوط به Debian 13 را بخوانید، در صورت امکان در یک VM تست کنید و بعد از ارتقای موفق، مخازن خارجی را وقتی از trixie پشتیبانی کردند دوباره فعال کنید.

#Debian #Debian13 #Linux #Sysadmin #APT #Upgrade #ReleaseNotes #Repositories

🟣لینک مقاله:
https://postgresweekly.com/link/174480/web


👑 @Database_Academy
👏2
🔵 عنوان مقاله
Tuning Asynchronous I/O (AIO) in Postgres 18

🟢 خلاصه مقاله:
در Postgres 18 قابلیت AIO اضافه شده که امکان ارسال هم‌زمان عملیات خواندن/نوشتن بدون بلوکه‌کردن پردازش‌ها را می‌دهد. نتیجه‌اش استفاده بهتر از CPU، افزایش توان عبوری و کاهش لگ‌های انتهای توزیع، به‌ویژه روی SSD/NVMe است. برای تیونینگ، از مقدارهای پیش‌فرض شروع کنید و با اندازه‌گیری دقیق جلو بروید؛ عمق صف مهم‌ترین اهرم است: عمق کم پهنا‌باند را هدر می‌دهد و عمق زیاد تاخیر را بالا می‌برد. اندازه‌ی دسته‌های ارسال، shared_buffers، و ریتم نوشتن‌های WAL/چک‌پوینت باید با نوع کار (OLTP در برابر تحلیل‌محور) و نوع دیسک تنظیم شوند. با pg_stat_io و رویدادهای انتظار در Postgres و ابزارهای سیستم‌عاملی مثل iostat، perf و pidstat پ99 تاخیر، صف‌ها و استفاده‌ی دیسک/CPU را پایش کنید. تفاوت‌های پلتفرمی مهم‌اند: روی Linux با io_uring، فایل‌سیستم‌ها (XFS/ext4/ZFS) و دیسک‌های ابری/شبکه‌ای رفتار متفاوتی دارند؛ HDD به عمق صف محافظه‌کارانه‌تر نیاز دارد و NVMe از عمق بیشتر سود می‌برد. در تمام مراحل، دوام (fsync، synchronous_commit) را با تست خرابی و بازیابی راستی‌آزمایی کنید. رویکرد مرحله‌ای—بالقوه با pgbench—و تنظیم تدریجی عمق صف و پارامترهای نوشتن، معمولاً بهترین کارایی پایدار را به‌همراه می‌آورد.

#Postgres #AIO #DatabasePerformance #io_uring #WAL #NVMe #Linux #Postgres18

🟣لینک مقاله:
https://postgresweekly.com/link/174756/web


👑 @Database_Academy