Странная ошибка при использовании du -h -d1

Вопрос или проблема

Я использую устаревший почтовый сервер… он просто работает на Courier Postfix и SMTP. Это VM на KVM и у него два диска, один для ОС и один для данных. У меня очень заполненный диск данных (показывает 100% заполненным, хотя используемое и доступное пространство составляет около 24 ГБ). Я не уверен, почему или что занимает место и затем освобождает его. top показывает, что в основном работает только imapd от Postfix. Я не могу запустить iotop на этой машине. Поэтому я решил начать освобождать место в почтовых ящиках пользователей на сервере, выполнив команду du -h -d1, чтобы попытаться узнать, какие из них самые крупные нарушители. Эта команда выполняется МЕДЛИТЕЛЬНО, медленнее, чем когда-либо. Поэтому, так как это выполнялось медленно, я решил выполнить команду screen:

du -h -d1 > mailboxsizes.txt

Чтобы утром вернуться к этому и посмотреть использование. Она записала около 6 почтовых ящиков, самый большой из которых 2.2 ГБ, а затем ничего. Я пришёл на саму машину, чтобы увидеть, что команда делает, если она всё ещё работает, и увидел это:

[root@xmail]# du -h -d1 > /root/mailboxsizes.txt
[14280.306953] INFO: task imapd:12559 blocked for more than 120 seconds.
[14280.307710] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[14280.309680] imapd           D ffff8800d3d9cd98     0 12559      1 0x00000080
[14280.310591]  ffff8800b17bbc20 0000000000000086 ffff880057bbce70 ffff8800b17bbfd8
[14280.310591]  ffff8800b17bbfd8 ffff8800b17bbfd8 ffff880057bbce70 ffff8800d3d9cd90
[14280.313532]  ffff8800d3d9cd94 ffff880057bbce70 00000000ffffffff ffff8800d3d9cd98
[14280.313532] Call Trace:
[14280.315669]  [<ffffffff8168d159>] schedule_preempt_disabled+0x29/0x70
[14280.316637]  [<ffffffff8168adb5>] __mutex_lock_slowpath+0xc5/0x1c0
[14280.316637]  [<ffffffff81208e17>] ? unlazy_walk+0x87/0x140
[14280.318543]  [<ffffffff8168a21f>] mutex_lock+0x1f/0x2f
[14280.319516]  [<ffffffff81683c93>] lookup_slow+0x33/0xa7
[14280.320690]  [<ffffffff8120c8f3>] path_lookupat+0x773/0x7a0
[14280.321718]  [<ffffffff81183775>] ? filemap_fault+0x215/0x410
[14280.321718]  [<ffffffff811de5e5>] ? kmem_cache_alloc+0x35/0x1e0
[14280.323363]  [<ffffffff8120f23f>] ? getname_flags+0x4f/0x1a0
[14280.324348]  [<ffffffff8120c94b>] filename_lookup+0x2b/0xc0
[14280.324348]  [<ffffffff81210367>] user_path_at_empty+0x67/0xc0
[14280.325307]  [<ffffffff811b1431>] ? handle_mm_fault+0x6b1/0xfe0
[14280.327150]  [<ffffffff812103d1>] user_path_at+0x11/0x20
[14280.327965]  [<ffffffff81203843>] vfs_fstatat+0x63/0xc0
[14280.328093]  [<ffffffff81203dae>] SYSC_newstat+0x2e/0x60
[14280.328093]  [<ffffffff81692875>] ? do_page_fault+0x35/0x90
[14280.330895]  [<ffffffff8168ea88>] ? page_fault+0x28/0x30
[14280.331790]  [<ffffffff8120408e>] SyS_newstat+0xe/0x10
[14280.331857]  [<ffffffff81697089>] system_call_fastpath+0x16/0x1b

Я новичок в администрировании систем и не имею ни малейшего представления о том, что это всё мне говорит, кроме чего-то, связанного с imapd? Я перезагружал эту машину несколько раз, и она практически не освободила место на жестком диске или, по-видимому, ресурсы. Я не могу понять, что происходит и почему du не сработал, как ожидалось. В основном я здесь спрашиваю, с чего даже начать? Хотя эта машина старая и всегда имела свои моменты, она никогда не делала этого раньше (хотя я понимаю, что на диске с данными мало места), но если я очищу его, то что-то его снова заполняет.

Для полноты картины:

df -h
Файловая система     Размер Использовано Доступно Использ % Смонтировано на
devtmpfs            2.9G        0      2.9G   0% /dev
tmpfs               2.9G        0      2.9G   0% /dev/shm
tmpfs               2.9G      41M      2.8G   2% /run
tmpfs               2.9G        0      2.9G   0% /sys/fs/cgroup
/dev/vda3          21G      18G      2.1G  90% /
/dev/vdb          459G     435G      442M 100% /mail
/dev/vda1         976M     119M      790M  14% /boot
tmpfs              581M        0      581M   0% /run/user/0
tmpfs              581M        0      581M   0% /run/user/1000

top - 06:06:53 up  6:52,  3 users,  load average: 36.42, 36.64, 31.74
Задачи: 346 всего, 8 работающих, 338 спящих, 0 остановленных, 0 зомби
%Cpu(s):  7.4 us,  1.2 sy,  0.0 ni,  0.0 id, 89.9 wa,  0.0 hi,  0.0 si,  1.5 st
KiB Память :  5946284 всего,  130280 свободно,  2278016 использовано,  3537988 buff/cache
KiB Swap:  2516988 всего,  1906332 свободно,   610656 использовано.  3362528 доступно

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
19174 postfix   20   0   27028   5504   1488 R   8.3  0.1   0:38.53 imapd       
19586 postfix   20   0   27028   5504   1488 D   7.6  0.1   0:32.18 imapd       
19008 postfix   20   0   27028   5504   1488 R   7.0  0.1   0:48.61 imapd       
19372 postfix   20   0   27464   5872   1504 D   4.3  0.1   0:30.38 imapd       
20087 postfix   20   0   27028   5504   1488 D   4.3  0.1   0:23.27 imapd       
20188 postfix   20   0   27028   5504   1488 D   4.3  0.1   0:23.31 imapd       
20353 postfix   20   0   27028   5508   1488 D   4.3  0.1   0:23.05 imapd       
19963 postfix   20   0   27028   5508   1488 D   4.0  0.1   0:23.85 imapd       
20275 postfix   20   0   27028   5508   1488 D   4.0  0.1   0:22.56 imapd       
18460 postfix   20   0   29348   5748   1588 R   3.7  0.1   0:38.09 imapd       
20236 postfix   20   0   27028   5516   1488 D   3.7  0.1   0:22.86 imapd       
   32 root      20   0       0      0      0 S   1.7  0.0   5:57.44 kswapd0     
20079 postfix   20   0   32728   9152   1520 S   1.7  0.2   0:01.90 imapd       
19702 postfix   20   0   27028   5516   1488 D   1.3  0.1   0:27.77 imapd       
18575 postfix   20   0   30472   6848   1596 D   1.0  0.1   0:14.86 imapd       
19782 postfix   20   0   27028   5508   1488 D   1.0  0.1   0:27.02 imapd       
 1026 root      20   0 1174028  22616   8992 S   0.7  0.4   2:53.90 fail2ban-s+ 

Я не знаю, на что смотреть и что пробовать, чтобы понять, где я могу просмотреть некоторые папки и узнать, чьи старые почтовые ящики мы держим, чтобы избавиться от них в попытке освободить место и, надеюсь, улучшить производительность сервера.

Единственная моя идея – временно остановить postfix с помощью systemctl и посмотреть, будет ли du и ls работать лучше, и дважды проверить, что top не будет перегружен в этом случае.

Также, на случай, если это имеет отношение, вот iostat:

iostat
Linux 3.10.0-514.16.1.el7.x86_64 (xmail)    11/21/2024  _x86_64_    (3 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.95    0.01    1.29   88.86    0.65    3.24

Устройство:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
vda              11.92       252.15        61.60    6335865    1547820
vdb            1517.62     62131.62        78.76 1561227117    1979120

Ответ или решение

К сожалению, у вас возникли серьезные проблемы с производительностью и управлением дисковым пространством на вашем почтовом сервере. Давайте рассмотрим основные аспекты вашего вопроса и шаги, которые вы можете предпринять для их решения.

Прежде всего, основные проблемы:

1. Полное дисковое пространство:
   Ваш диск /dev/vdb на 459 ГБ показывает 100% использование, хотя вы упоминаете, что у вас есть около 24 ГБ доступного пространства. Это говорит о возможных проблемах с файловой системой или недоступными/привязанными к моментальным образам файлами.

2. Повышенная загрузка CPU и задержка процессов:
   Процессы imapd из postfix показывают высокий уровень блокировки, что может указывать на проблемы с доступом к диску или файловой системе. Это также объясняет медленное выполнение команд, таких как du.

Анализ вывода:

• Команда du -h -d1 используется для определения размера директорий, но в вашем случае она выполняется медленно, и мы видим сообщения о блокировке imapd. Это может быть вызвано тем, что imapd пытается получить доступ к файлам, блокируя du и мешая нормальному функционированию.
• Высокий уровень iowait (88.86%) указывает на то, что процессор ожидает, когда устройство ввода-вывода завершит операции. Это может быть следствием недостаточной производительности диска или конфликтов доступа.

Рекомендуемые действия:

1. Остановка службы postfix:
   Остановка почтового сервера временно может помочь вам проверить текущее состояние диска и выполнить команды du и ls без конфликтов. Запустите команду:

   systemctl stop postfix

   Затем проверьте выполнение команд:

   du -h -d1 /mail > /root/mailboxsizes.txt

2. Проверка файловой системы:
   После остановки сервиса стоит провести проверку файловой системы на наличие ошибок. Используйте команду:

   fsck /dev/vdb

   Убедитесь, что у вас есть резервные копии важных данных перед проведением этой операции.

3. Оптимизация хранения почты:
   Проверьте, не содержат ли ваши почтовые ящики временные или заблокированные элементы, такие как большие вложения или неиспользуемые данные, которые можно удалить. Это может быть выполнено с помощью команд управления почтой или скриптов для очистки.

4. Мониторинг использованию дискового пространства:
   Убедитесь, что у вас установлены утилиты мониторинга, такие как ncdu, которые могут помочь анализировать используемое дисковое пространство более эффективно и с меньшим влиянием на производительность.

5. Рассмотрите возможность обновления оборудования:
   Если проблема сохраняется, возможно, стоит рассмотреть вариант увеличения объёма дискового пространства или улучшения производительности (например, путем перехода на SSD).

6. Отключение несущественных процессов:
   Проверьте другие запущенные процессы, которые могут использовать дисковое пространство или ресурсы, и отключите те, которые не являются необходимыми.

Заключение:

Проблемы с производительностью и управлением дисковым пространством могут вызвать значительные затруднения в функционировании вашего почтового сервера. Следуя вышеуказанным рекомендациям, вы сможете выявить корень проблемы и предпринять шаги для их устранения. Рекомендуется также поддерживать регулярные проверки и мониторинг системы, чтобы предотвратить возникновение подобных проблем в будущем.