مستندات Stalwart به دو پرسش ظرفیتسنجی خوب جواب میدهد: یک نصب خیلی کوچک چه می‌خواهد، و یک نود در کلاستر چند صندوق پستی را تحمل میکند. اما بازه‌ای که بیشتر سازمان‌ها واقعاً در آن هستند، یعنی از چند صد تا چند هزار صندوق، به عهدهٔ خود شما گذاشته شده است. این مقاله همین فاصله را با تکیه بر خود مستندات پر میکند و سه سطح ۲۰۰، ۲۰۰۰ و ۱۰٬۰۰۰ صندوق پستی را جداگانه بررسی میکند.
یک نکته را از همین ابتدا بگوییم. ما Stalwart را برای یک دانشگاه با ۱۰٬۰۰۰ صندوق پستی در محیط عملیاتی اجرا می‌کنیم، ولی تست بار انجام نداده‌ایم و عدد بنچمارکی هم منتشر نمی‌کنیم. هر عددی که در ادامه می‌بینید یا مستقیم از مستندات خود Stalwart نقل شده و لینکش آمده، یا حساب سادهٔ ضرب و تقسیم است که می‌توانید با سهمیه‌های خودتان دوباره انجامش دهید.
ظرفیتسنجی Stalwart در یک نگاه
| تعداد صندوق | تعداد نود | ذخیره‌سازها | سقف دیسک با سهمیهٔ ۵ گیگابایت |
|---|---|---|---|
| ۲۰۰ | ۱ | RocksDB برای هر چهار نقش (پیشفرض Docker) | ۱ ترابایت |
| ۲۰۰۰ | از نظر ظرفیت ۱ نود کافی است | PostgreSQL برای داده، ذخیره‌ساز سازگار با S3 برای blobها | ۱۰ ترابایت |
| ۱۰٬۰۰۰ | ۱ نود از پسش برمی‌آید؛ برای دسترسپذیری بالا ۳ نود یا بیشتر | ذخیره‌سازهای مشترک: PostgreSQL یا FoundationDB، blob توزیع‌شده، موتور جست‌وجو، Redis یا Valkey | ۵۰ ترابایت |
تعداد نودها از صفحهٔ ظرفیتسنجی Stalwart آمده، ستون دیسک حاصل ضرب ساده در سهمیه است، و مصرف واقعی معمولاً خیلی پایین‌تر از این سقف است (در بخش ۱۰٬۰۰۰ صندوق ببینید یک سرور عملیاتی واقعاً چقدر داده نگه می‌دارد).
مستندات Stalwart دقیقاً چه تعهدی میدهد
- حافظه در حالت بیکار: حدود ۱۰۰ مگابایت، طبق صفحهٔ پیش‌نیازهای سیستم.
- نصبهای کوچک: همان صفحه می‌گوید ۱ گیگابایت رم معمولاً برای حدود ۵ تا ۱۰ کاربر کافی است و یک هستهٔ CPU برای یک راه‌اندازی کم‌ترافیک با حدود پنج کاربر.
- اتصال‌ها: بهطور پیشفرض تا ۸۱۹۲ اتصال هم‌زمان، که بین IMAP، JMAP، WebDAV، SMTP و POP3 تقسیم میشود. پایین آوردن این سقف مصرف حافظه را هم پایین می‌آورد.
- به ازای هر نود: صفحهٔ ظرفیتسنجی کلاستر می‌گوید یک نود که درست پیکربندی شده باشد ۱۰٬۰۰۰ تا ۵۰٬۰۰۰ صندوق فعال را جواب میدهد، و در محیط‌های پرمصرف بهتر است برای هر ۵۰۰۰ تا ۱۰٬۰۰۰ کاربر فعال یک نود در نظر بگیرید.
- دسترسپذیری بالا: حداقل سه نود، ترجیحاً تعداد فرد. وقتی یکی از منابع روی ۷۰ تا ۸۰ درصد ماند، نود اضافه کنید و از اول برای دو تا سه برابر بار شروع کار ظرفیت بگذارید.
به چیزی که نیست دقت کنید: نه عددی برای رم به ازای هر صندوق وجود دارد و نه هیچ عددی برای دیسک. این کمبودی نیست که با یک پست در فروم برطرف شود. مصرف حافظهٔ Stalwart بیشتر به تنظیمات کش بستگی دارد و مصرف دیسکش به این‌که چه backend ذخیرهسازی به آن وصل کرده‌اید.
حافظه بیشتر صرف کش میشود، پس انتخابش با شماست
صفحهٔ کارایی کش متادیتای ایمیل را مهم‌ترین کش میداند، چون کلاینت‌های IMAP مدام به آن سر می‌زنند، و می‌خواهد آن‌قدر حافظه داشته باشید که متادیتای همهٔ کاربرانی که هم‌زمان وصل‌اند در کش جا شود. مرجع کش مقادیر پیشفرض را آورده است: ۵۰ مگابایت برای متادیتای پیام‌ها، ۲۰ مگابایت برای حساب‌ها، ۱۰ مگابایت برای هر کدام از مخاطبان، رویدادها، فایل‌ها و توکن‌های دسترسی، و چند کش کوچک DNS. این پیش‌فرض‌ها عمداً محتاطانه انتخاب شده‌اند.
پس قاعدهٔ عملی این است: با همان پیش‌فرض‌ها شروع کنید، در یک صبح شلوغ حافظهٔ مقیم (resident) پروسه و شاخص‌های cache hit سرور را زیر نظر بگیرید، و هر وقت نرخ hit افت کرد کش پیام را بزرگ‌تر کنید. سروری که بعد از یک import سنگین IMAP «بیشتر از چیزی که مستندات گفته رم مصرف میکند» معمولاً فقط دارد کش‌هایش را تا سقف پر میکند، و کش برای همین کار ساخته شده.
ذخیرهسازی یک تصمیم نیست، چهار تصمیم است
Stalwart ذخیرهسازی را به چهار نقش تقسیم میکند که در صفحهٔ انتخاب پایگاه داده توضیح داده شده‌اند:
- Data store: متادیتا، مثل پوشه‌ها، فلگ‌ها، تقویم‌ها، مخاطبان و تنظیمات.
- Blob store: متن پیام‌ها و پیوست‌ها؛ تقریباً همهٔ دیسک شما همین‌جا مصرف میشود.
- Search store: ایندکس‌های جست‌وجوی تمام‌متن.
- In-memory store: داده‌های کوتاه‌عمر برای محدودیت نرخ، نشست‌ها، کلاسترینگ و بررسی اسپم.
روی یک نود می‌توانید هر چهار نقش را در یک backend بگذارید. نصب Docker همه را بهطور پیشفرض روی RocksDB و دیسک محلی می‌گذارد، و خود Stalwart هم RocksDB را برای نصب تک‌نودی توصیه میکند. برای کلاستر، صفحهٔ ذخیرهسازی کلاستر FoundationDB را برای داده پیشنهاد میکند، PostgreSQL را گزینهای بالغ و خوش‌کارایی میداند، برای جست‌وجو یک موتور اختصاصی مثل Elasticsearch یا Meilisearch می‌خواهد (پایگاه دادهٔ همه‌منظوره آن‌جا write amplification اضافه میکند)، و برای دادهٔ درون‌حافظه‌ای Redis یا Valkey. یکی از هشدارهای مستندات را باید عیناً جدی گرفت: عوض کردن backend در آینده یعنی مهاجرت داده. طوری انتخاب کنید که انگار همین الان ۱۰٬۰۰۰ صندوق دارید.
دیسک: حسابش را خودتان بکنید
چون مستندات عددی نمی‌دهد، blob store را بر اساس سیاست سهمیه‌تان اندازه بگیرید. مثلاً ۲۰۰ صندوق با سهمیهٔ ۵ گیگابایت یعنی سقف ۱ ترابایت، و ۲۰۰۰ صندوق با همان سهمیه یعنی ۱۰ ترابایت. بیشتر صندوق‌ها هیچ‌وقت به سهمیه‌شان نمی‌رسند و مصرف واقعی کمتر خواهد بود، ولی پشتیبانگیری و برنامهٔ رشد را باید حول همین سقف چید. برای ایندکس جست‌وجو هم جا بگذارید، و یادتان باشد چیزی که صفحهٔ ظرفیتسنجی برای تحویل پیام، ایندکس‌کردن و جست‌وجو حیاتی میداند سرعت I/O ذخیره‌ساز است، نه حجم آن.
۲۰۰ صندوق پستی
یک نود کاملاً کافی است. RocksDB برای هر چهار ذخیره‌ساز کار را ساده نگه می‌دارد، و چون Stalwart فیلتر اسپم داخلی دارد، Rspamd جداگانه‌ای هم نیست که برایش ظرفیت حساب کنید. کف ۱ گیگابایتی مستندات برای پنج تا ده کاربر است، پس به سرور ۲۰۰ کاربره بیشتر از این بدهید و برای کش جا بگذارید. مستندات عددی به ازای هر کاربر منتشر نکرده، پس به جای حدس زدن، بعد از اولین هفتهٔ شلوغ اندازه بگیرید. وقتی چند ده گوشی هم‌زمان همگام‌سازی کنند، داشتن بیش از یک هسته به کار می‌آید. برای پشتیبانگیری از کل volume داده snapshot بگیرید و یک بار هم، قبل از این‌که لازمش داشته باشید، بازیابی را امتحان کنید.
۲۰۰۰ صندوق پستی
طبق اعداد خود مستندات، این هنوز خیلی پایین‌تر از ظرفیت یک نود است. اگر این‌جا چیزی را تغییر می‌دهید، دلیلش عملیات است، نه ظرفیت. وقتی data store به PostgreSQL و blobها به ذخیره‌ساز شیء سازگار با S3 منتقل شوند، پشتیبانگیری، replication و مانیتورینگ با ابزارهایی انجام میشود که تیمتان احتمالاً همین حالا دارد، و سرور ایمیل دیگر یک استثنای عجیب در زیرساخت نیست. اگر کاربران زیاد در ایمیل‌های قدیمی جست‌وجو می‌کنند، این‌جا همان نقطه‌ای است که موتور جست‌وجوی اختصاصی کم‌کم ارزشش را نشان میدهد. قبل از مهاجرت دادن کلاینت‌ها مطمئن شوید پورت submission یعنی ۵۸۷ واقعاً در حال گوش دادن است؛ در نصب ما بهطور پیشفرض فعال نبود.
۱۰٬۰۰۰ صندوق پستی
روی کاغذ یک نود از پس این تعداد برمی‌آید. سؤال اصلی در این اندازه این است که اگر همان یک نود صبح شنبه از کار بیفتد چه میشود. مستندات می‌گوید دسترسپذیری بالا از سه نود شروع میشود. ما هم همین‌طور برنامهریزی کردیم: چند نود Stalwart روی ذخیره‌سازهای مشترک، متادیتا در PostgreSQL با یک replica، blob پیام‌ها در MinIO توزیع‌شده، یک message bus برای هماهنگی و HAProxy در جلو. سرور عملیاتی امروز هنوز تک‌نودی کار میکند و همه چیز در PostgreSQL است، و این دقیقاً همان ریسکی است که آن طرح قرار است حذفش کند. جزئیات، از جمله مشکلاتی که با مدل پیکربندی نسخهٔ 0.16 داشتیم، در مقایسهٔ mailcow، Stalwart و Mailu در مقیاس ۱۰٬۰۰۰ صندوق آمده است.
برای این‌که تصویری از مصرف واقعی داشته باشید، نه سهمیه: در ۳۰ سپتامبر ۲۰۲۶ نود عملیاتی ما (Stalwart 0.16.13، ۲۴ هسته، ۶۰ گیگابایت رم) برای حدود ۱۰٬۰۰۰ صندوق نزدیک ۵۵۹ گیگابایت داده در PostgreSQL داشت، با همهٔ پیام‌ها و پیوست‌ها داخل پایگاه داده. این بهطور میانگین حدود ۵۶ مگابایت به ازای هر صندوق میشود، یعنی کسر کوچکی از هر سهمیهٔ معمولی، و دیسک ۳ ترابایتی‌اش ۴۳ درصد پر بود. این عدد مال یک سرور در یک لحظه است و بنچمارک حساب نمی‌شود، ولی نشان میدهد سقف سهمیه چقدر دیسک لازم در روز اول را بیشتر از واقعیت نشان میدهد. این‌که آن صندوق‌ها را چطور منتقل کردیم در برنامهٔ مهاجرت به سرور ایمیل اختصاصی آمده و جنبهٔ هزینه‌اش در این مطالعهٔ موردی.
دو نکتهٔ احتیاطی. مستندات برای راه‌اندازی توزیع‌شده FoundationDB را توصیه میکند و build پیشفرض Docker آن را ندارد، پس اگر این مسیر را می‌روید یک build سفارشی در برنامه بگذارید. ما PostgreSQL را انتخاب کردیم چون از قبل بلد بودیم اجرایش کنیم. دیگر این‌که طبق مقایسهٔ نسخه‌های Stalwart، read replica و ذخیره‌سازهای shardشده جزو قابلیت‌های نسخهٔ Enterprise هستند؛ کلاسترینگ پایه در نسخهٔ Community هست.
Stalwart در برابر Dovecot: دو چیز متفاوت را اندازه می‌گیرید
Dovecot یک سرور IMAP و POP3 است. یک نصب معمول Dovecot پشت Postfix برای SMTP می‌نشیند، Rspamd برای اسپم کنارش است و اغلب یک سرور CalDAV جدا هم دارد، پس باید ظرفیت چهار پنج daemon را حساب و همه را جداگانه وصله کنید. Stalwart یک باینری Rust است که SMTP، IMAP، POP3، JMAP، CalDAV، CardDAV و WebDAV را با فیلتر اسپم داخلی انجام میدهد، پس ظرفیت یک پروسه و ذخیره‌سازهایش را حساب میکنید. Dovecot چند دهه سابقهٔ عملیاتی و حجم عظیمی دانش تنظیم و بهینه‌سازی پشتش دارد. اگر Postfix و Dovecot شما درست کار میکند، مصرف منابع بهتنهایی دلیل خوبی برای عوض کردن نیست. دلایل بهتر، گستردگی پروتکل‌ها، JMAP و اجرای یک سرویس به جای پنج سرویس است.
اگر دسترسی خروجی سرورتان محدود است
صفحهٔ پیشنیازها اتصال‌های خروجیای را که سرور لازم دارد فهرست کرده است: GitHub releases برای بستهٔ رابط وب مدیریت در اولین اجرا (بدون آن، /admin خطای 404 میدهد)، دایرکتوری ACME برای گواهیها، و DNS روی پورت ۵۳. در شبکهٔ بسته، این‌ها را قبل از روز نصب حل کنید، نه وسط آن. دیوار بعدی تحویل‌پذیری ایمیل است؛ راهنمای خطای Outlook 550 5.7.515 برای سرورهای اختصاصی بررسی‌های لازم را توضیح داده است.
FanMail کجای این تصویر است
FanMail لایهٔ وب‌میل و مدیریتی است که ما روی Stalwart ساخته‌ایم: یک کلاینت JMAP برای کاربران و یک پنل مدیریت برای سرور، که روی زیرساخت خود شما نصب میشود. ظرفیتسنجی بالا بدون تغییر برای آن هم صدق میکند، چون سرور ایمیل زیرش همان Stalwart معمولی است. برای این‌که ببینید اصلاً در اندازهٔ سازمان شما راه‌اندازی سرور اختصاصی صرفه دارد یا نه، ماشین‌حساب هزینهٔ ایمیل اختصاصی را امتحان کنید. چرا وب‌میل را روی JMAP ساختیم و نه IMAP، در JMAP در برابر IMAP برای وب‌میل توضیح داده شده است.
اگر دارید این گزینه را با یک سرویس میزبانی‌شده مقایسه میکنید، بررسی ما از قیمت‌گذاری Zoho Mail در ۲۰۲۶ همهٔ پلن‌ها و کمبودهای هر کدام را فهرست کرده است.
پرسش‌های متداول
حداقل پیش‌نیازهای سیستمی Stalwart چیست؟
طبق مستندات Stalwart، مصرف رم در حالت بیکار حدود ۱۰۰ مگابایت است، ۱ گیگابایت معمولاً برای ۵ تا ۱۰ کاربر کافی است و یک هستهٔ CPU یک راه‌اندازی کم‌ترافیک با حدود پنج کاربر را پوشش میدهد. حداقل رسمی برای دیسک وجود ندارد، چون مصرف دیسک به backend ذخیرهسازی و سهمیه‌ها بستگی دارد.
Stalwart برای ۲۰۰ کاربر چقدر رم لازم دارد؟
Stalwart عددی به ازای هر کاربر منتشر نمیکند. بیشتر حافظه صرف کشهایی میشود که خودتان تنظیم میکنید، پس بالاتر از کف ۱ گیگابایتی نصبهای کوچک شروع کنید، کشها را روی پیشفرض نگه دارید و بر اساس حافظهٔ مقیم و نرخ cache hit در ساعات اوج، ظرفیت را بالا ببرید.
یک نود Stalwart چند صندوق پستی را جواب میدهد؟
طبق صفحهٔ ظرفیتسنجی کلاستر Stalwart، یک نود که درست پیکربندی شده باشد بسته به الگوی استفاده، همزمانی و سرعت backend بین ۱۰٬۰۰۰ تا ۵۰٬۰۰۰ صندوق فعال را جواب میدهد. برای دسترسپذیری بالا، مستندات دستکم سه نود را توصیه میکند.
با Stalwart از RocksDB استفاده کنم یا PostgreSQL؟
RocksDB گزینهٔ توصیهشده برای تکنود و پیشفرض Docker است. برای کلاستر، مستندات FoundationDB را توصیه میکند و PostgreSQL را گزینهای بالغ میداند. تغییر در آینده به مهاجرت داده نیاز دارد، پس زود تصمیم بگیرید.
Stalwart به ازای هر صندوق پستی چقدر دیسک لازم دارد؟
Stalwart عددی برای دیسک به ازای هر صندوق منتشر نمیکند، چون به backend ذخیرهسازی و میزان ایمیلی که افراد نگه میدارند بستگی دارد. پشتیبانگیری و رشد را حول سقف سهمیه (تعداد صندوق ضرب در سهمیه) برنامهریزی کنید. به عنوان یک دادهٔ واقعی، سرور ۱۰٬۰۰۰ صندوقی ما حدود ۵۵۹ گیگابایت داده داشت، یعنی بهطور میانگین نزدیک ۵۶ مگابایت برای هر صندوق.
آیا Stalwart از Dovecot سبکتر است؟
این دو کارهای متفاوتی انجام میدهند، پس مقایسهٔ مستقیم گمراهکننده است. Dovecot یک سرور IMAP و POP3 است که معمولاً کنار Postfix، Rspamd و یک سرور CalDAV اجرا میشود. Stalwart یک پروسه است که SMTP، IMAP، POP3، JMAP، CalDAV، CardDAV و WebDAV را با فیلتر اسپم داخلی پوشش میدهد. کل پشتهٔ Dovecot را با یک نود Stalwart مقایسه کنید، نه Dovecot را بهتنهایی.
سرور Stalwart به چه دسترسی خروجیای نیاز دارد؟
طبق صفحهٔ پیشنیازها: GitHub releases برای دانلود رابط وب مدیریت در اولین اجرا، دایرکتوری ACME (مثل Let's Encrypt) برای گواهیها، و DNS روی پورت ۵۳ با UDP و TCP، یا DNS over HTTPS اگر پیکربندی شده باشد.
