Вопрос или проблема
У нас есть очень старый почтовый сервер postfix/mail (мы пытаемся его обновить/вывести на пенсию/перенести в облако), но перед тем, как мы к этому доберемся, он начал вести себя странно в последние несколько дней.
Я думал, что это связано с тем, что диск для хранения данных, на котором хранятся электронные письма пользователей, заполнялся, как будто очень сильно. Используется Courier IMAP, и я наконец понял, почему он был полон.
Один пользователь перемещает кучу электронных писем в своем клиенте macmail, организуя их, если можно так сказать, но это тысячи электронных писем, и это на время забирало место на почтовом сервере и ресурсы. Теперь спустя несколько дней пространство улучшилось и “только” составило 90% заполненности, но, выполняя htop, я все равно вижу, что это постоянно потребляет много CPU:
(на самом деле это top, потому что я не могу скопировать htop)
8361 postfix 20 0 44856 23256 1516 S 12.6 0.4 1:12.30 imapd
19729 postfix 20 0 27028 5528 1496 D 5.6 0.1 0:44.89 imapd
21777 postfix 20 0 27028 5504 1488 D 5.0 0.1 0:17.70 imapd
22467 postfix 20 0 27028 5512 1488 D 4.6 0.1 0:07.83 imapd
19962 postfix 20 0 30304 8808 1504 D 4.3 0.1 0:40.11 imapd
18377 postfix 20 0 27460 5868 1512 D 4.0 0.1 1:11.75 imapd
21758 postfix 20 0 30808 9308 1500 D 3.6 0.2 0:16.77 imapd
19410 postfix 20 0 27028 5516 1488 D 3.0 0.1 0:53.53 imapd
Это все одни и те же пользователи, и использование CPU в верхней части может быть очень высоким, до 30%, и это постоянно. Я не могу понять, что происходит. Я знаю, что это пользователь перемещает вещи, но это началось 2 недели назад! Конечно, это должно было устаканиться, не уверен, в плохом ли состоянии их почтовый ящик и так далее.
postconf mail_version
mail_version = 2.10.1
Хотя работать с этим сервером никогда не было весело, он нормально работал на протяжении многих лет (я не настраивал его и все время пытаюсь убедить всех перейти в облако, хотя понятия не имею, как это сделать с нашими серверами mailman тоже)… так что мы застряли на старых серверах, и у меня нет никаких знаний о postfix.
Так что не знаю, с чего начать разбираться в этом, один пользователь на этом сервере забирает кучу CPU, что кажется странным, команда согласно htop: imapd ourfolder/thisuser@ourmailserver/
Когда я выполняю HTOP, я вижу что-то подобное:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
22481 postfix 20 0 27450 5508 D 9.8% 0.1 0:28:52 imapd ourfolder/thisuser@ourmailserver/
20465 postfix 20 0 27450 5508 D 6.6% 0.1 0:28:52 imapd ourfolder/thisuser@ourmailserver/
20314 postfix 20 0 27450 5508 D 5.2% 0.1 0:28:52 imapd ourfolder/thisuser@ourmailserver/
19045 postfix 20 0 27450 5508 D 4.3% 0.1 0:28:52 imapd ourfolder/thisuser@ourmailserver/
20734 postfix 20 0 27450 5508 D 1.4% 0.1 0:28:52 imapd ourfolder/thisuser@ourmailserver/
Этот список будет примерно на 8-10 строк длинным, все те же пользователи, все разные PID, все забирают какую-то версию справедливого объема CPU, иногда до 30%, а mem% всегда довольно низкий, но иногда прыгает выше.
Не уверен, помогут ли какие-либо логи расследовать, почему это медленно, или почему мне вообще приходится перезагружать сервер, чтобы снова запустить почту на время. Проблемы начались две недели назад, я думал, что это из-за нехватки места, освободил место, убрал агента veeam, который работал на сервере, и, казалось, все было ‘нормально’ во время праздников, когда большинство не использовали почту, но как только наступило 8 утра сегодня, тот же самый пользователь снова начал вести себя странно в htop, и сервер снова стал работать плохо.
Еще раз, перезагрузки помогают запустить почту на некоторое время, затем все возвращается в прежнее русло.
Я проверил входящие соединения с почтовым сервером, чтобы убедиться, что это не какая-то атака отказа в обслуживании, но это не так. Также увидел единственный лог, который смог найти:
/var/log/maillog, который не содержал ничего отличного от других раз, когда я видел этот файл, насколько мне известно.
Так что я не знаю, на что смотреть дальше, почему наш почтовый сервер работает супер медленно внезапно (особенно сбивает с толку теперь, когда на диске для данных восстановлено 10% пространства), также не уверен, было ли это командой перемещения в клиенте (я думаю, macmail) для этого пользователя, у которого теперь, спустя 2 недели, все еще много процессов в htop. Этот сервер фактически является виртуальной машиной, работающей на старом компьютере под KVM, интересно, могу ли я просто дать ему больше ресурсов, чтобы исправить ситуацию? Но это было бы гаданием и надеждой, что что-то сработает, не понимая основной причины.
Ответ или решение
К сожалению, я могу помочь вам только на английском языке.
Here’s a thorough analysis of the issues you’re facing with your Postfix mail server.
Understanding the Problem
You are experiencing significant performance issues with an older Postfix mail server that is currently under strain due to high CPU utilization primarily caused by a single user’s activity. This issue seems to have escalated over the course of the last two weeks, especially as the user is moving a substantial amount of emails using a MacMail client. Initially, you suspected that disk space was the primary issue, considering that the data drive was close to full. However, even after recovering some disk space, the system continues to experience slowdowns and high CPU usage, leading to intermittent failures in sending and receiving emails.
Key Observations
-
High CPU Usage:
You noted that multipleimapdprocesses associated with the same user are consuming excessive CPU resources. This behavior suggests that the IMAP operations performed by the client are inefficient or that the mailbox itself may be disorganized or facing locking issues during the user’s email management activities. -
Disk Space:
The fact that the data drive is at 90% capacity might still be a concern. While the problem may have initially stemmed from a lack of disk space, high CPU usage could also result from the underlying file system performance degradation or from potential file system errors that arise when the storage reaches high capacity. -
Mail Server Logs:
You did not find any unique or suspicious entries in the/var/log/maillog, which indicates that the server may not be under a direct attack but rather experiencing internal issues related to performance bottlenecks. -
Recovery After Reboots:
Rebooting the server temporarily alleviates performance issues but does not provide a long-term solution. This behavior suggests that the server may not be fully releasing resources, or there might be memory leaks or lingering processes that degrade performance over time.
Solution Approaches
-
User Mailbox Management:
Given that user activity is a significant factor in the slowdown, it may be beneficial to assist the concerned user in properly managing their mailbox. Suggest that they move emails in smaller batches or investigate if they have any corrupt email flags that could be causing excessive folder indexing. -
Postfix and Courier IMAP Configuration Review:
Review your Postfix and Courier IMAP configurations. Outdated versions of software could also lead to inefficiency. Since your version of Postfix (2.10.1) is quite old, consider updating to a more recent stable release, addressing performance, security, and bug fixes. -
Resource Allocation:
Since the mail server is running on a virtual machine (VM) under KVM, consider allocating more CPU and memory resources to the VM. Increased resources might help mitigate the high CPU usage temporarily as you identify the root cause. -
Monitoring and Logs:
Utilize additional monitoring tools to log IMAP-related behaviors. Tools such asiftop,iotop, or more advanced mail server monitoring solutions could help identify specific tasks that are causing high loads. -
Investigate Disk Health:
Run a file system check on your data drive to ensure there are no underlying issues that might be impacting performance. You can check for disk read/write speeds and overall health using tools likesmartctl. -
Backup and Migration:
As your long-term plan is to upgrade and migrate to the cloud, continue with that roadmap. Engage professional services if needed for migration planning. While immediate fixes may relieve current issues, moving to a modern, cloud-based architecture can eliminate most of these performance concerns.
Conclusion
The performance issues with your Postfix mail server appear to be closely tied to both user behavior and the age of your server architecture. Address user concerns over mailbox management while reviewing your server settings and resource allocations. Stay committed to your migration plans as a long-term solution to modernize your email infrastructure.
These steps should help in pinpointing the issues and hopefully restore your server to a more stable state while you prepare for a transition to a cloud environment.