تصور کنید یک کاربر چت با هوش مصنوعی را می‌بندد یا ارتباطش قطع می‌شود، اما در پس‌زمینه، سرور شما همچنان در حال پردازش یک کوئری سنگین و بیهوده است. این نشت منابع پنهان می‌تواند کل سیستم شما را در ساعات پیک ترافیک فلج کند.
وقتی یک عامل (Agent) — شبیه به کارمندی که دستورات شما را می‌گیرد و به ابزارهای مختلف پاس می‌دهد — با خطای تایم‌اوت در پروتکل زمینهٔ مدل (MCP) مواجه می‌شود، توسعه‌دهندگان معمولاً گمان می‌کنند پردازش متوقف شده است. اما طبق گزارش فنی منتشر شده در ۳۰ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، کوئری‌های زیرساختی در PostgreSQL اغلب به کار خود ادامه می‌دهند. این اتفاق باعث می‌شود اتصالات موجود در استخر (Connection Pool) اشغال بمانند و ردیف‌های داده بدون هیچ کاربر نهایی، اسکن شوند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی زیرساخت‌های عامل‌محور اشاره کردیم، مدیریت چرخهٔ حیات درخواست‌ها در سیستم‌های توزیع‌شده پیچیدگی‌های خاص خود را دارد. مشکل اصلی این است که تایم‌اوت‌ها در لایه‌های مختلف و مجزا تعریف شده‌اند: عامل یک ضرب‌الاجل دارد، لایه انتقال MCP تایم‌اوت مخصوص خود را دارد و استخر اتصالات محدودیت‌های جذب دارد. به نقل از مستندات فنی مذکور، دریافت خطای ۵۰۴ تنها ثابت می‌کند که پروکسی منتظر نمانده است، اما هیچ تضمینی نمی‌دهد که پایگاه‌داده کار را متوقف کرده است.
برای اطمینان از آمادگی سیستم در محیط عملیاتی، توسعه‌دهندگان باید تست‌های دقیقی را اجرا کنند. به طور مشخص، اجرای دستور SELECT pg_backend_pid(), pg_sleep(30); از طریق درایور واقعی و مسیر شبکه، تنها راه تایید لغو عملیات است. یک زنجیره لغو (Cancellation Chain) مقاوم باید چهار مورد را تایید کند:
- کلاینت خطای ضرب‌الاجل (Deadline Error) را دریافت کرده باشد.
- ابزار MCP تمام کارهای فعال و صف‌بندی شده را متوقف کرده باشد.
- در جدول
pg_stat_activityدیگر اثری از آن دستور نباشد. - اتصال استخر بلافاصله برای کوئری بعدی در دسترس باشد.
باید به «شرایط رقابتی» (Race Conditions) توجه ویژه‌ای داشت؛ مثلاً زمانی که در حین استریم داده‌ها یا در وضعیت انتظار برای یک قفل (Lock)، ارتباط قطع می‌شود. اگر فراخواننده در حالی که منتظر دریافت اتصال از استخر است لغو شود، نباید کوئری ۱۰ ثانیه بعد — وقتی اتصالی آزاد شد — شروع به اجرا کند.
از آنجا که لغو در سطح اپلیکیشن ممکن است شکست بخورد یا کرش کند، محدودیت‌های سمت پایگاه‌داده آخرین خط دفاعی هستند. بر اساس توصیه‌های فنی، باید سیاست‌های اجرای محدود برای نقش‌های خاص تعریف شود. برای مثال، نقش ai_readonly باید با statement_timeout ۱۵ ثانیه‌ای، lock_timeout ۲ ثانیه‌ای و idle_in_transaction_session_timeout ۱۰ ثانیه‌ای محدود شود.
این تغییر رویکرد، «پشتیبانی از تایم‌اوت» را از یک ویژگی مبهم به یک قرارداد قابل تست تبدیل می‌کند. برای توسعه‌دهنده، این یعنی عبور از مرحله دمو و رسیدن به اثباتی که سیستم می‌تواند به همان اندازه که کار را شروع می‌کند، آن را متوقف کند.
گام بعدی شما
- کوئری‌های طولانی‌مدت خود را با
pg_stat_activityدر حین قطع ارتباط کلاینت مانیتور کنید. - برای نقش‌های دسترسی هوش مصنوعی، محدودیت‌های
statement_timeoutرا در سطح دیتابیس اعمال کنید. - تست لغو عملیات را به بخشی از خط لوله (Pipeline) تست‌های یکپارچگی خود اضافه کنید.
اما مدیریت حافظه در لایه‌های بالاتر، یعنی در خودِ مدل‌ها، چالش‌های متفاوتی دارد — به بررسی ما درباره‌ی بهینه‌سازی KV Cache مراجعه کنید.
گفتگو