- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Приветствую!
Вообщем с недавнего времени ОЧЕНЬ странный глюк на сервере, не с того не с сего медленно копятся процессы пачками, до 1000 штук за час и все в ожидании, причём и LA растёт соответственно до 1000, ну что там уже говорить, память съедается вся, и всё тормазит.
root SN /USR/SBIN/CRON
exim DN /usr/sbin/sendmail -i -FCronDaemon -oem user
(пара процессов)
я так понимаю запускаются кроновские, а потом от эксима сендмаил, и висят в паре кучами
в письмах там отправляются в основном ошибки пхп запущенного через крон...
начал копать, да, CRON ждёт sendmail, а вот sendmail долго открывает фаил /var/spool/exim4/input/...
через lsof и strace отследил что долго висит на такой строке
open("/var/spool/exim4/input//hdr.25688"
далее прогружает так
fchown(4, 103, 105) = 0
fchmod(4, 0640) = 0
fcntl(4, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(4, {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffd5f36a000
lseek(4, 0, SEEK_CUR) = 0
write(4, "1PJvGv-0006gK-OY-H\numarov 1244 12"..., 318) = 318
fstat(4, {st_mode=S_IFREG|0640, st_size=318, ...}) = 0
write(4, "185P Received: from umarov by s1."..., 678) = 678
fsync(4) = 0
fstat(4, {st_mode=S_IFREG|0640, st_size=996, ...}) = 0
close(4) = 0
munmap(0x7ffd5f36a000, 4096) = 0
rename("/var/spool/exim4/input//hdr.25688", "/var/spool/exim4/input//1PJvGv-0006gK-OY-H") = 0
open("/var/spool/exim4/input//.", O_RDONLY) = 4
fsync(4) = 0
close(4) = 0
и т.д.
/var/spool/exim4/input// - смущает странное присутствие второго слеша во всех путях...
пытаюсь просмотреть эту папку
dir - висит бесконечно, хотя фалов то на самом деле всего 4тыс, как буд-то блокируется чтение директории...
пытаюсь читать один из файлов (less file) в этой папки, читает сразу, либо просто везёт...
но если файла нет, всё также висит несколько минут, потом пишет файла нет.
что делать, удаление папки также зависло, но слава богу переименовывает без проблем, переименовал в input2, система разгрузилась через 5 мин.
Смотрю что там, читает обе папки без проблем:
s1:/var/spool/exim4# dir input2 -la|wc -l
4750
s1:/var/spool/exim4# dir input -la|wc -l
74
после переименовки система работает нормально, но часов 12, не более, потом картина повторяется...
Кто нибудь знает что это за странный глюк такой, неужели RAID разваливается?
На сервере запущено не мало сайтов, что ещё можно посмотреть чтобы определить причину такого зависания?
Зарание спасибо за любую помощь ;)
Без доступа к серверу сказать трудно
Доступ дать не могу, не подскажите куда копать и что ещёсмотреть, чтобы выявить причину?
Может просто сбои на файловой системе - иначе трудно объяснить почему при 4 к файлов система так напрягается. А отсюда и тормоза при обращении эксима к рабочим директориям. Не мешало бы сделать fsck наверное.
Как выяснилось, это общий перегруз диска, не знаю почему именно на exim это так влиеяет что чтение папки зависает(может приоритеты на чтение), но факт что сам диск через atop busy 99%
Далее если смотреть через atop кто и как грузит диск, больше всего это оказывается журнал
78% kjournald
Не подскажите как облегчить ситуацию? Пора отключать крупные сайты и переносить на другие сервера? )
Как более точно определить что и кто именно грузит HDD, может atop врёт и это вовсе не журнал.
noatime может немного облегчит жизнь.
спасибо!
и ещё заметил что nginx уж больно усердно пишет на диск, видимо все полученные ответы кеширует, с этим можно что-то сделать? )
PID RDDSK WRDSK WRDSK_CANCEL DSK CMD 1/34
24290 0K 39920K 168K 91% nginx
у него есть опция proxy_temp_file_write_size
максимальный объем данных который nginx пишет на диск за один прием.
можно ее уменьшить, например proxy_temp_file_write_size=64k
что-то не очень всё это дело с буферами помогает
proxy_buffer_size 4k;
proxy_buffers 8 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
надо задумываться о SAS дисках?
надо задумываться о SAS дисках?
Это задумываться об администраторе =)
Dimanych, проверь файловую систему :)