процессор в целом свободен, а задача всё равно упирается

Разбираюсь с обработкой файлов. В общей картинке CPU будто не занят, а процесс долго жуёт один файл, следующий ждёт. Если открыть по потокам, один загружен заметно сильнее остальных. Я правильно понимаю, что добавленные ядра сами по себе такую штуку не ускорят? Раньше смотрел только на общий процент и думал, что процессор ни при чём.

kirill_nsk общий процент легко прячет один занятый поток среди свободных. Но сначала выясни, что делает сам процесс: считает, ждёт диск, сеть или блокировку. Если работа действительно последовательная, свободные ядра за неё не возьмутся. Несколько независимых файлов иногда можно обрабатывать параллельно, только память тогда тоже считаем.

kirill_nsk попробуй отдельно измерить один файл без очереди. Если задержка уже там, добавление работников не сократит её автоматически. А если одиночный проходит быстро, но в очереди ждёт долго, это уже другая задача. Полезно разделить время ожидания и время самой обработки.

lexa92 вот, время в очереди у меня в ту же цифру попадало. Разнесу замеры. А то я сравнивал один файл с пачкой и уверенно делал вид, что это одинаковый тест.

Вынес ожидание отдельно. Теперь в отчёте две цифры, и хотя бы ясно, где тормозит. Пока не добавлял параллельных работников: хочу сначала понять, сколько один съедает памяти на большом файле. Спасибо, отучаете лечить непонятное количеством ядер.

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

gleb_tomsk взял для проверки самый большой файл, отдельно записал его размер и время обработки. Пока больше ничего не менял. Уже нравится, что могу сравнить два прогона, а не вспоминать «вроде вчера быстрее было».

kirill_nsk вот теперь можно менять по одному параметру. Только исходный вариант сохрани, чтобы было к чему вернуться. Самое обидное — получить «быстрее», но уже не помнить, какие три настройки одновременно тронул.

kirill_nsk, пиковое потребление памяти одного процесса можно снять через /usr/bin/time -v: посмотри строку Maximum resident set size. Средняя загрузка между задачами может скрывать короткий пик. Если замерить тот же большой файл при одном работнике, а потом при нескольких, будет проще сравнить память и время без смены остальных настроек.

alisa_sd, у Maximum resident set size важно проверить единицы для своей системы. Ещё полезны page faults, но большое их число само по себе не доказывает своп: часть промахов обходится без дискового чтения, а дисковое чтение может быть связано с отображёнными файлами. Для вывода о свопе нужны дополнительные замеры. У kirill_nsk есть показатели памяти именно во время медленного прогона?

igor_kzn писал:
большое их число само по себе не доказывает своп: часть промахов обходится без дискового чтения, а дисковое чтение может быть связано с отображёнными файлами

У меня дома ровно этот случай каждый день. Когда гружу большую модель в ComfyUI (видеокарта 12 гб, половина весов живёт в обычной памяти), page faults взлетают до небес: веса читаются с диска через mmap, и система честно считает каждый промах. А своп как был нулём, так и остался. Проверяла vmstat 1 в соседнем терминале: si и so — нули, хотя фолтов тысячи.

По единицам тоже подтверждаю: на убунте Maximum resident set size — в килобайтах. Я первый раз прочитала число как байты и минут пять радовалась, что процесс съел всего три мегабайта )

kirill_nsk, если замеров именно на медленном прогоне ещё нет, самый простой путь — vmstat 1 в соседнем окне и смотреть si/so в тот момент, когда тормозит. Нули — своп ни при чём, можно идти в диск или в сам код. А пик памяти без сторонних утилит видно в /proc/<pid>/status, строка VmHWM, обновляется на живую.

alisa_sd запустил vmstat в соседнем окне, si и so нули весь прогон. значит не своп? а VmHWM глянуть не успел, процесс умер раньше меня 🤦

alisa_sd вернулся с цифрами, в этот раз подготовленный))

сделал как ты сказала. на том же большом файле запустил через /usr/bin/time -v, а в соседнем окне цикл который каждые пару секунд дёргает VmHWM из /proc. строку цикла честно подсмотрел, сам бы такую не написал. pid правда сначала не тот взял и минут пять пялился в статус какого-то левого процесса 🤦 потом по htop нашёл правильный. зато в этот раз работник не умер раньше меня, я за ним следил как ястреб.

вот что в конце вылезло:

Maximum resident set size (kbytes): 1487232

я чуть не обрадовался что это байты, вовремя вспомнил твои три мегабайта) выходит полтора гига. VmHWM примерно столько же на пике показал, 1390000 с копейками, то есть сходится. прогнал два раза подряд, цифры почти те же, плюс минус пятьдесят мегабайт, так что это не случайный всплеск а правда столько ест.

si so нули весь прогон. я теперь в vmstat смотрю как в телевизор, даже когда всё нормально.

igor_kzn вот и замеры именно на медленном. файл девятьсот мегабайт, идёт минуты четыре, пик памяти ближе к концу.

итого. свопа нет. проц свободен. один работник на самом жирном файле — полтора гига. у меня uab, там 4 всего. два работника на двух больших файлах — уже три плюс система. gleb_tomsk твоё «оставляй запас» оказалось не теорией, а буквально вот этой арифметикой. исходный конфиг сохранил как ты велел, меняю по одному.

теперь вопросы, без них никак.

если не своп и не проц, значит диск или сам код, ты так писала. на диск куда смотреть, iostat? я его один раз запустил и закрыл, там колонок как в экселе. какая из них важная?

и ограничение очереди — это в самой очереди настраивается или systemd такое умеет? чтоб два больших файла на двух работниках не встретились одновременно.

alisa_sd договорю, что в конце обрезалось) два работника на двух больших файлах — это уже три гига из моих четырёх. блин. то есть я всё это время упирался не в проц, а в память на пике?

и gleb_tomsk походу прав был, что два больших рано или поздно встретятся. вопрос теперь такой. когда памяти не хватает, он начинает файл с диска перечитывать, как у тебя с моделью? и проц поэтому свободен — просто ждёт? куда смотреть, чтобы это поймать?

kirill_nsk вот за этим и нужны были цифры, а не мои «вроде». Полтора гига по двум независимым замерам, и они сошлись между собой — красота)). Я прав был наполовину: угадал, что два больших рано или поздно встретятся, а вот что ты это докажешь за пару дней с VmHWM и циклом из честно подсмотренной строки — не ожидал, респект.

kirill_nsk писал:
когда памяти не хватает, он начинает файл с диска перечитывать

Да, только механика чуть другая, чем с весами модели у alisa_sd. Свопа нет, поэтому когда два работника съедают три гига из четырёх, ядру надо что-то выкинуть — и оно жмёт единственное, что можно выкинуть безболезненно: дисковый кэш. Твой файл на девятьсот мегабайт честно лежал в памяти после первого чтения, а теперь его оттуда вытесняют. Работник доходит до куска, которого в кэше уже нет, и читает с диска по новой. Всё это время он не считает — он ждёт. Снаружи выглядит ровно как твой симптом: процессор свободен, задача ползёт.

Причём «свободен» — в кавычках. В том же vmstat, куда ты теперь смотришь как в телевизор, есть колонка wa: это и есть «процессор сидит и ждёт диск». Рядом bi — блоки, которые реально прилетают с диска. Поймай медленный прогон с двумя работниками: si/so по-прежнему нули, а wa и bi подскочат. Ответ без единой новой утилиты.

Вторая улика у тебя уже есть, ты её просто пролистал. В выводе /usr/bin/time -v есть строка Major (requiring I/O) page faults — это промахи, которые пошли за данными на диск. Сравни её на двух прогонах: один работник против двух. Ставлю на разницу раз в десять. Если опять накосячил с прогнозом — поправлюсь завтра, я так умею)).

И домашний бенчмарк на субботу. Один большой файл, два прогона подряд: второй должен быть заметно быстрее, файл уже в кэше. Потом то же самое с двумя работниками на двух больших — кэш на оба не влезает, и оба прогона одинаково медленные. Если картина именно такая, диагноз закрыт. Я со своей стороны сегодня погоняю похожее на восьми гигах, вечером сравним.

Что делать. Дешёвый вариант: большие файлы в отдельную очередь, один работник, пусть ждут своей очереди — пик полтора гига ты теперь знаешь, режь по нему. Дорогой: у меня heka, восемь гигабайт, там два таких работника влезают и на кэш ещё остаётся. Но сначала очередь, она бесплатная.

Кстати, а что у тебя ещё крутится на этих четырёх гигах? Если там докер-зверинец с вебмордой, работникам достаётся не 4, а гига три, и всё съезжается ещё раньше. Скинь free -m в спокойном состоянии — интересно, насколько я жесток в прогнозах ))

kirill_nsk, у меня с моделью ровно эта картина: процессор гуляет, а wa скачет. Я тогда полчаса грешила на видеокарту, а оказалось — диск, да )