[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$favOa2GnnyLUFooEF7Pafoe2UQzdS3EkPL7fEx0FY-L8":3},{"data":4,"related":97},{"id":5,"title":6,"slug":7,"excerpt":8,"cover":9,"category":11,"author":14,"track":20,"level":23,"reading_minutes":26,"is_featured":27,"published_at":28,"updated_at":28,"body":29,"toc":30,"tags":66,"faqs":81,"related_services":91,"comments_enabled":95,"meta_title":19,"meta_description":96,"canonical_url":19,"noindex":27,"is_live":95},4,"حلقه بی‌پایان Jira Automation: وقتی قانون خودش را صدا می‌زند","jira-automation-infinite-loop-fix","اگر trigger و action یک قانون Jira Automation روی یک رویداد بیفتند، قانون خودش را دوباره اجرا می‌کند و issue با صدها کامنت تکراری پر می‌شود. این مقاله علت، پاک‌سازی و راه‌حل پایدار را نشان می‌دهد.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F696958ce-e1fa-458e-b7df-1f1a99fe6a5f.webp",{"name":12,"slug":13},"CI\u002FCD و اتوماسیون","cicd",{"name":15,"slug":16,"role":17,"bio":18,"linkedin_url":19,"avatar_url":19},"تحریریه کلودیکپ","cloudicap-editorial","تیم محتوای کلودیکپ","تیم فنی و محتوای کلودیکپ؛ مهندسانی که هر روز با DevOps، Kubernetes و زیرساخت ابری کار می‌کنند و تجربه‌هایشان را اینجا می‌نویسند.",null,{"value":21,"label":22},"engineers","مهندسان",{"value":24,"label":25},"intermediate","متوسط",7,false,"2026-10-07T09:28:33+00:00","\u003Ch2 id=\"نشانه-مشکل-issue-به-یک-ربات-کامنت‌ساز-تبدیل-می‌شود\">نشانه مشکل: issue به یک ربات کامنت‌ساز تبدیل می‌شود\u003C\u002Fh2>\n\u003Cp>صبح دوشنبه چند نفر همزمان پیام می‌دهند که «تسک OPS-1423 دیوانه شده». issue را باز می‌کنی و می‌بینی ۴۰۰ کامنت پشت سر هم با متن یکسان زیر آن نشسته، وضعیت بین \u003Ccode>In Review\u003C\u002Fcode> و \u003Ccode>Done\u003C\u002Fcode> بالا و پایین می‌پرد و صندوق ایمیل watcherها پر شده است. مهم‌ترین سرنخ این است که همه کامنت‌ها یک author مشترک دارند: \u003Cstrong>Automation for \u003Ca href=\"\u002Fservices\u002Fjira-self-hosted\">Jira\u003C\u002Fa>\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>اگر به مسیر \u003Ccode>Project settings > Automation > Audit log\u003C\u002Fcode> بروی، تصویر واضح‌تر می‌شود: یک قانون در چند ثانیه چند صد بار اجرا شده و هر اجرا با وضعیت Success ثبت شده است. این الگو تقریباً همیشه یعنی یک چیز: قانون دارد خودش را trigger می‌کند.\u003C\u002Fp>\n\u003Cblockquote>نشانه قطعی حلقه این است که تعداد اجراهای audit log با تعداد رویدادهای واقعی تیم هم‌خوانی ندارد. اگر ۵ نفر در روز کامنت می‌گذارند ولی قانون ۹۰۰ بار اجرا شده، مشکل پیکربندی است نه رفتار کاربران.\u003C\u002Fblockquote>\n\n\u003Ch2 id=\"علت-ریشه‌ای-trigger-و-action-روی-یک-رویداد-می‌افتند\">علت ریشه‌ای: trigger و action روی یک رویداد می‌افتند\u003C\u002Fh2>\n\u003Cp>سناریوی رایج این است که قانونی شبیه زیر ساخته شده:\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Trigger:\u003C\u002Fstrong> \u003Ccode>Issue commented on\u003C\u002Fcode> با شرطی که متن کامنت شامل کلمه \u003Ccode>deploy\u003C\u002Fcode> باشد.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Action:\u003C\u002Fstrong> انتقال issue به \u003Ccode>Done\u003C\u002Fcode> و افزودن کامنت «✅ Deployed by pipeline».\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>اجرای اول از یک کامنت واقعی تیم شروع می‌شود. قانون issue را به Done می‌برد و کامنتی می‌گذارد که... خودش شامل کلمه deploy است. پس دوباره شرط trigger برقرار می‌شود، دوباره transition، دوباره کامنت. هر دور یک ورودی تازه برای دور بعد می‌سازد و حلقه تا وقتی چیزی جلویش را نگیرد ادامه دارد.\u003C\u002Fp>\n\u003Cp>سه عامل این وضعیت را بدتر می‌کنند:\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>\u003Cstrong>خروجی action همان ورودی trigger است.\u003C\u002Fstrong> ریشه‌ی اصلی همین است؛ نه Jira، نه سرعت، نه بار سرور.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>اجازه‌ی trigger شدن قانون توسط قوانین دیگر.\u003C\u002Fstrong> در تنظیمات هر قانون گزینه‌ای با عنوان \u003Cem>Allow other rule actions to trigger this rule\u003C\u002Fem> وجود دارد که اگر فعال باشد، action یک قانون می‌تواند قانون دیگر (یا خودش) را دوباره بیدار کند.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>ترکیب چند قانون روی یک رویداد.\u003C\u002Fstrong> یک قانون کامنت می‌گذارد، قانون دوم روی «Issue commented on» گوش می‌دهد و وضعیت را عوض می‌کند، قانون سوم دوباره کامنت می‌گذارد. حلقه بین دو یا سه قانون شکل می‌گیرد، نه داخل یکی.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Jira در بعضی موارد پس از تعداد زیادی اجرا در بازه کوتاه، قانون را غیرفعال می‌کند. این یک تور محافظتی است، نه راه‌حل؛ تا وقتی قانون را درست نکنی، اولین فعال‌سازی دستی دوباره حلقه را روشن می‌کند.\u003C\u002Fp>\n\n\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\n\n\u003Ch3 id=\"۱-قانون-را-همین-حالا-خاموش-کن\">۱) قانون را همین حالا خاموش کن\u003C\u002Fh3>\n\u003Cp>قبل از هر کار دیگری جلوی خون‌ریزی را بگیر. برای قوانین پروژه‌ای: \u003Ccode>Project settings > Automation\u003C\u002Fcode> و کلید قانون را خاموش کن. برای قوانین سراسری: \u003Ccode>Settings > System > Automation rules\u003C\u002Fcode>. خاموش کردن، اجرای در جریان را متوقف نمی‌کند اما از دور بعد جلوگیری می‌کند.\u003C\u002Fp>\n\n\u003Ch3 id=\"۲-مقیاس-خرابی-را-از-audit-log-بردار\">۲) مقیاس خرابی را از audit log بردار\u003C\u002Fh3>\n\u003Cp>در audit log فیلدهای زمان اجرا، نام قانون و وضعیت را ببین. اگر زمان شروع مشخص است، می‌توانی بازه‌ی آلودگی را دقیق تعیین کنی: آستانه‌ی زمانی قبل از شروع را در جست‌وجوهای بعدی استفاده کن.\u003C\u002Fp>\n\n\u003Ch3 id=\"۳-issueهای-آلوده-را-با-jql-پیدا-کن\">۳) issueهای آلوده را با JQL پیدا کن\u003C\u002Fh3>\n\u003Cp>متن کامنتی که ربات می‌گذاشته را به‌عنوان اثر انگشت استفاده کن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">project = OPS AND comment ~ \"Deployed by pipeline\" AND updated >= -1d ORDER BY updated DESC\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>عملگر \u003Ccode>~\u003C\u002Fcode> روی فیلد \u003Ccode>comment\u003C\u002Fcode> یک جست‌وجوی متنی است، پس دقیقاً همان کامنت‌های تکراری را برمی‌گرداند و issueهای سالم را کنار می‌گذارد.\u003C\u002Fp>\n\n\u003Ch3 id=\"۴-کامنت‌های-تکراری-را-با-rest-api-پاک-کن\">۴) کامنت‌های تکراری را با REST API پاک کن\u003C\u002Fh3>\n\u003Cp>Jira در UI حذف گروهی کامنت ندارد. اول \u003Ccode>accountId\u003C\u002Fcode> ربات را از یکی از کامنت‌های آلوده بردار:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">curl -s -u \"$JIRA_EMAIL:$JIRA_TOKEN\" \\\n  \"https:\u002F\u002Fyour-domain.atlassian.net\u002Frest\u002Fapi\u002F3\u002Fissue\u002FOPS-1423\u002Fcomment?maxResults=1\" \\\n  | python3 -c \"import sys,json; print(json.load(sys.stdin)['comments'][0]['author']['accountId'])\"\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>سپس اسکریپت زیر را اجرا کن. این اسکریپت فقط کامنت‌هایی را حذف می‌کند که author آن‌ها همان اکانت ربات است، پس کامنت‌های واقعی تیم دست‌نخورده می‌مانند:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-python\">import os\nimport time\nimport requests\n\nBASE = os.environ[\"JIRA_BASE\"].rstrip(\"\u002F\")   # https:\u002F\u002Fyour-domain.atlassian.net\nAUTH = (os.environ[\"JIRA_EMAIL\"], os.environ[\"JIRA_TOKEN\"])\nBOT_ID = os.environ[\"AUTOMATION_ACCOUNT_ID\"]\nAPI = f\"{BASE}\u002Frest\u002Fapi\u002F3\"\n\n\ndef search(jql):\n    keys, token = [], None\n    while True:\n        params = {\"jql\": jql, \"maxResults\": 100, \"fields\": \"key\"}\n        if token:\n            params[\"nextPageToken\"] = token\n        r = requests.get(f\"{API}\u002Fsearch\u002Fjql\", auth=AUTH, params=params, timeout=30)\n        r.raise_for_status()\n        data = r.json()\n        keys += [i[\"key\"] for i in data.get(\"issues\", [])]\n        token = data.get(\"nextPageToken\")\n        if not token:\n            return keys\n\n\ndef iter_comments(key):\n    start = 0\n    while True:\n        r = requests.get(\n            f\"{API}\u002Fissue\u002F{key}\u002Fcomment\",\n            auth=AUTH,\n            params={\"startAt\": start, \"maxResults\": 100},\n            timeout=30,\n        )\n        r.raise_for_status()\n        data = r.json()\n        batch = data.get(\"comments\", [])\n        for c in batch:\n            yield c\n        start += len(batch)\n        if not batch or start >= data.get(\"total\", 0):\n            return\n\n\ndef purge(key):\n    removed = 0\n    for c in iter_comments(key):\n        if c[\"author\"].get(\"accountId\") == BOT_ID:\n            r = requests.delete(\n                f\"{API}\u002Fissue\u002F{key}\u002Fcomment\u002F{c['id']}\", auth=AUTH, timeout=30\n            )\n            if r.status_code in (200, 204):\n                removed += 1\n            time.sleep(0.1)          # مرز ایمن برای rate limit\n    return removed\n\n\nif __name__ == \"__main__\":\n    jql = 'project = OPS AND comment ~ \"Deployed by pipeline\" AND updated >= -1d'\n    for k in search(jql):\n        print(k, purge(k))\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر روی نسخه‌ای از Jira هستید که \u003Ccode>\u002Fsearch\u002Fjql\u003C\u002Fcode> را ندارد، همان تابع \u003Ccode>search\u003C\u002Fcode> را به \u003Ccode>\u002Frest\u002Fapi\u002F3\u002Fsearch\u003C\u002Fcode> و صفحه‌بندی \u003Ccode>startAt\u003C\u002Fcode> تغییر بده؛ بقیه‌ی منطق یکی است.\u003C\u002Fp>\n\n\u003Ch3 id=\"۵-قانون-را-بدون-حلقه-بازنویسی-کن\">۵) قانون را بدون حلقه بازنویسی کن\u003C\u002Fh3>\n\u003Cp>سه الگو را به ترتیب اولویت امتحان کن:\u003C\u002Fp>\n\u003Col>\n  \u003Cli>\u003Cstrong>trigger را از «کامنت» به «تغییر فیلد» منتقل کن.\u003C\u002Fstrong> اگر تریگر روی \u003Ccode>Field value changed\u003C\u002Fcode> برای یک فیلد مثل \u003Ccode>Deploy Status\u003C\u002Fcode> باشد و action آن فیلد را تغییر ندهد، حلقه از پایه غیرممکن می‌شود.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>گارد بگذار.\u003C\u002Fstrong> اگر مجبوری روی کامنت تریگر بزنی، بلافاصله بعد از trigger یک \u003Ccode>Advanced compare condition\u003C\u002Fcode> اضافه کن: مقدار اول \u003Ccode>{{comment.body}}\u003C\u002Fcode>، شرط \u003Cem>does not contain\u003C\u002Fem>، مقدار دوم \u003Ccode>Deployed by pipeline\u003C\u002Fcode>. کامنتی که خود ربات می‌گذارد شرط را رد می‌کند و کار تمام است.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>عنوان قانون را در متن action تکرار نکن.\u003C\u002Fstrong> متن کامنت ربات را طوری بنویس که هیچ‌وقت با کلمه‌ی کلیدی trigger هم‌پوشانی نداشته باشد. کامنت واقعی بهتری هم می‌شود.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Ch3 id=\"۶-محافظ‌های-سطح-پلتفرم\">۶) محافظ‌های سطح پلتفرم\u003C\u002Fh3>\n\u003Cul>\n  \u003Cli>در تنظیمات قانون، گزینه‌ی \u003Cem>Allow other rule actions to trigger this rule\u003C\u002Fem> را غیرفعال نگه دار.\u003C\u002Fli>\n  \u003Cli>قوانین را با یک پروژه‌ی sandbox تست کن و فقط بعد از دیدن یک اجرای تمیز روی پروژه‌ی واقعی فعالش کن.\u003C\u002Fli>\n  \u003Cli>مالکیت قانون را به یک سرویس‌اکانت اختصاصی بده تا خروج فرد از تیم باعث از کار افتادن قانون نشود.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"چطور-مطمئن-شویم-مشکل-واقعا-حل-شده\">چطور مطمئن شویم مشکل واقعاً حل شده\u003C\u002Fh2>\n\u003Cp>سه بررسی کوتاه کافی است:\u003C\u002Fp>\n\u003Col>\n  \u003Cli>\u003Cstrong>تست دستی روی یک issue آزمایشی:\u003C\u002Fstrong> کامنتی بگذار که کلمه‌ی کلیدی را ندارد. باید هیچ اتفاقی نیفتد. بعد کامنتی با کلمه‌ی کلیدی بگذار؛ باید دقیقاً یک transition و یک کامنت اضافه شود.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>شمارش در audit log:\u003C\u002Fstrong> بعد از تست، تعداد اجراهای قانون باید برابر تعداد رویدادهای واقعی باشد، نه بیشتر. اگر عدد بزرگ‌تر بود، گارد دوم لازم داری.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>پایش ۱۰ دقیقه‌ای:\u003C\u002Fstrong> JQL را دوباره اجرا کن و تعداد کامنت‌های ربات را با تعداد قبلی مقایسه کن. عدد باید ثابت بماند.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>یک JQL سریع برای این پایش:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">project = OPS AND comment ~ \"Deployed by pipeline\" AND updated >= -10m\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\n\u003Cul>\n  \u003Cli>\u003Cstrong>قاعده‌ی طلایی:\u003C\u002Fstrong> هیچ actionی نباید رویدادی تولید کند که trigger همان قانون (یا قانون دیگری) روی آن گوش می‌دهد.\u003C\u002Fli>\n  \u003Cli>برای هر قانون حداکثر یک مسئولیت تعریف کن. قانونی که هم وضعیت را عوض می‌کند هم کامنت می‌گذارد هم فیلد ویرایش می‌کند، سه کاندید حلقه است.\u003C\u002Fli>\n  \u003Cli>قوانین \u003Ccode>Issue commented on\u003C\u002Fcode> گران‌ترین تریگرها برای نگهداری‌اند؛ اگر می‌توانی روی transition یا تغییر فیلد تریگر بزن.\u003C\u002Fli>\n  \u003Cli>قبل از فعال‌سازی هر قانون جدید، به سؤال «اگر این action دوباره اجرا شود چه می‌شود؟» جواب بده.\u003C\u002Fli>\n  \u003Cli>audit log را هفتگی چک کن. جهش ناگهانی تعداد اجرا اولین نشانه‌ی حلقه است، حتی وقتی هنوز کسی شکایتی نکرده.\u003C\u002Fli>\n  \u003Cli>پس از حل مشکل، محتوای قانون را در مخزن IaC یا مستندات تیم ثبت کن تا فرد بعدی همان ابتدا گاردها را ببیند.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Jira Automation ابزار قدرتمندی است و بیشتر خرابی‌هایش از خود Jira نیست؛ از طراحی rule است. اگر trigger و action را روی دو رویداد جدا نگه داری، ۹۰٪ حلقه‌های بی‌پایان هیچ‌وقت شکل نمی‌گیرند.\u003C\u002Fp>",[31,35,38,41,45,48,51,54,57,60,63],{"id":32,"text":33,"level":34},"نشانه-مشکل-issue-به-یک-ربات-کامنت‌ساز-تبدیل-می‌شود","نشانه مشکل: issue به یک ربات کامنت‌ساز تبدیل می‌شود",2,{"id":36,"text":37,"level":34},"علت-ریشه‌ای-trigger-و-action-روی-یک-رویداد-می‌افتند","علت ریشه‌ای: trigger و action روی یک رویداد می‌افتند",{"id":39,"text":40,"level":34},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":42,"text":43,"level":44},"۱-قانون-را-همین-حالا-خاموش-کن","۱) قانون را همین حالا خاموش کن",3,{"id":46,"text":47,"level":44},"۲-مقیاس-خرابی-را-از-audit-log-بردار","۲) مقیاس خرابی را از audit log بردار",{"id":49,"text":50,"level":44},"۳-issueهای-آلوده-را-با-jql-پیدا-کن","۳) issueهای آلوده را با JQL پیدا کن",{"id":52,"text":53,"level":44},"۴-کامنت‌های-تکراری-را-با-rest-api-پاک-کن","۴) کامنت‌های تکراری را با REST API پاک کن",{"id":55,"text":56,"level":44},"۵-قانون-را-بدون-حلقه-بازنویسی-کن","۵) قانون را بدون حلقه بازنویسی کن",{"id":58,"text":59,"level":44},"۶-محافظ‌های-سطح-پلتفرم","۶) محافظ‌های سطح پلتفرم",{"id":61,"text":62,"level":34},"چطور-مطمئن-شویم-مشکل-واقعا-حل-شده","چطور مطمئن شویم مشکل واقعاً حل شده",{"id":64,"text":65,"level":34},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[67,69,72,75,78],{"name":68,"slug":68},"jira",{"name":70,"slug":71},"Atlassian","atlassian",{"name":73,"slug":74},"Jira Automation","jira-automation",{"name":76,"slug":77},"JQL","jql",{"name":79,"slug":80},"REST API","rest-api",[82,85,88],{"question":83,"answer":84},"چطور بفهمم حلقه از داخل یک قانون است یا از تعامل چند قانون؟","در audit log نام قانونی که مکرراً اجرا شده را ببین. اگر فقط یک نام تکرار می‌شود، حلقه درون همان قانون است. اگر دو یا سه نام به‌صورت زنجیره‌ای پشت سر هم اجرا می‌شوند، action یک قانون، trigger قانون بعدی را فعال می‌کند و باید گارد را روی همان حلقه‌ی بین‌قانونی بگذاری.",{"question":86,"answer":87},"آیا حذف کامنت‌های ربات با REST API روی تاریخچه‌ی issue اثر منفی دارد؟","کامنت حذف‌شده در تاریخچه باقی نمی‌ماند، اما transitionها و changelog دست‌نخورده می‌مانند. چون اسکریپت فقط کامنت‌های متعلق به accountId ربات را حذف می‌کند، بحث‌های واقعی تیم از بین نمی‌رود. پیش از اجرا، یک نسخه از کلید issueهای هدف را جایی ذخیره کن.",{"question":89,"answer":90},"چرا Jira خودش قانون را بعد از حلقه غیرفعال نکرد؟","Jira در بعضی موارد پس از تعداد زیادی اجرا در بازه کوتاه، قانون را به‌عنوان محافظت غیرفعال می‌کند، اما این رفتار تضمینی نیست و به بار و نسخه‌ی پلتفرم بستگی دارد. راه‌حل پایدار، افزودن شرط گارد در خود قانون است تا حلقه هرگز شکل نگیرد.",[92,93,94],"managed-devops","jira-self-hosted","performance-cost-optimization",true,"علت حلقه بی‌پایان Jira Automation، پاک‌سازی کامنت‌های تکراری با REST API و بازنویسی قانون بدون trigger شدن توسط action خودش.",[98,111,125],{"id":44,"title":99,"slug":100,"excerpt":101,"cover":102,"category":104,"author":107,"track":108,"level":109,"reading_minutes":26,"is_featured":27,"published_at":110,"updated_at":110},"قطع شدن WebSocket در HAProxy هر ۵۰ ثانیه؛ علت و راه‌حل","haproxy-websocket-timeout-50s","اگر WebSocket یا SSE پشت HAProxy هر ۵۰ ثانیه قطع می‌شود، مقصر تایماوت‌های پیش‌فرض فایل نمونه است. در این مقاله علت ریشه‌ای و پیکربندی درست timeout tunnel را بررسی می‌کنیم.",{"url":103,"alt":99},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F26b583b4-d805-45d6-a265-a94d73b5a21d.webp",{"name":105,"slug":106},"Linux و مدیریت سرور","linux",{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-07T07:57:29+00:00",{"id":34,"title":112,"slug":113,"excerpt":114,"cover":115,"category":117,"author":120,"track":121,"level":122,"reading_minutes":123,"is_featured":27,"published_at":124,"updated_at":124},"پرشدن دیسک PostgreSQL با WAL اسلات replication غیرفعال","postgresql-replication-slot-wal-disk-full","یک replication slot غیرفعال می‌تواند pg_wal را تا پر شدن کامل دیسک نگه دارد و دیتابیس را عملاً از کار بیندازد. در این مقاله ریشه‌یابی، رفع و پیشگیری از آن را گام‌به‌گام بررسی می‌کنیم.",{"url":116,"alt":112},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F88c82e31-0162-4db1-835f-5c86fba77647.webp",{"name":118,"slug":119},"مانیتورینگ و پایداری","monitoring",{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},6,"2026-10-06T17:39:51+00:00",{"id":126,"title":127,"slug":128,"excerpt":129,"cover":130,"category":132,"author":133,"track":134,"level":135,"reading_minutes":136,"is_featured":27,"published_at":137,"updated_at":137},1,"«idle in transaction» در PostgreSQL: قاتل خاموش autovacuum","postgres-idle-in-transaction-autovacuum-bloat","نشست‌های idle in transaction تراکنش را باز نگه می‌دارند، جلوی autovacuum را می‌گیرند و جدول‌ها را باد می‌کنند تا جایی که دیسک پر و اتصال‌ها تمام می‌شود. این مقاله تشخیص و درمان کامل آن است.",{"url":131,"alt":127},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F40aa29f7-e1d0-4c30-94f6-631ea9a173a0.webp",{"name":118,"slug":119},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},8,"2026-10-06T17:33:36+00:00"]