Как при старте и в процессе работы поддерживать информацию о скорости диска?



Дано: программа периодически пишет на диск файлы размером 10-1000 мб. Задача: при старте и в процессе работы поддерживать информацию о скорости диска (ну, например, представим что мы хотим рисовать правдивый progress bar).Как оценить скорость работы устройства на старте, когда ещё ничего не записали? Как изменить оценку после записи файла? Скользящее среднее не очень подходит, т.к. файлы пишутся периодически, т.е. диск загружен непостоянно.
51   37  
  1. Alexey Rybak месяц назад
    Прокалибровать системную информацию о дисковой подсистеме какой-то константой, а потом - смотреть по факту и менять оценку? Пишется же файл наверняка порциями, можно в процессе понять текущую скорость.
  2. Ilya Golshtein месяц назад
    Похоже на поиск моментальной средней температуры по больнице.
  3. Андрей Ковбович месяц назад
    А что за скорость диска? Скорость вращения постоянна. Число Direct и Cached IO по идее можно брать из ОС.
    • Роман Цисык месяц назад
      хочется давать ответ на вопрос "За какое время запишется chunk размером n" исходя из полученных результатов за прошлые периоды.
    • Андрей Ковбович месяц назад
      Можно попробовать выставить всем процессам квоты на IO. Тогда можно будет знать сколько гарантированно есть у вашего процесса ресурсов на чтение и запись.
  4. Тимур Сафин месяц назад
    Как-то так?
  5. Anton Barsukov месяц назад
    blktrace
    • Kostja Osipov месяц назад
      Anton Barsukov не снаружи и не с правами рута, а в самом процессе выполняющем запись.
  6. Ильнар Борханов месяц назад
    А если мерить записано сколько и за сколько времени, поддерживать в среднем только его, не вариант?
    • Kostja Osipov месяц назад
      Вариант, да. Вопрос что на старте делать, пока ничего ещё не записано.
  7. Алексей Еремихин месяц назад
    Попробую предложить решение в общем виде. Интересно предсказать скорость записи на диск. Для любого предсказания нужна тренированная модель. Пусть линейная в виде одного коэффициента в виде средней скорости записи. Вероятно модель придётся обучать с учётом текущего прогресса. Дальше стоит учесть конкуррентность записи и в частности конкурренцию от неучтённых факторов. Вдруг на тот же диск еще кто-то бекапы льёт. Теперь можно прикинуть, что у модели может быть на входе. Текущая скорость записи, iowait, util, длинну очереди на контроллере, предыдущее состояние модели, Объем данных для записи. Что с флашем? Вероятно важным будет объём свободной памяти. Системные параметры можно снять vmstat iostat. Ну и собрать из этого какую-то предсказалку упростив задачу до пары самых важных в конкретном случае параметров. Можно сделать несколько простых моделей от одного параметра. В полной неизвестности я бы взял среднюю скорость предыдущей записи и util для диска. Util предположил бы линейным или табличным. И калибровал (обучал) бы его по предыдущим экспериментам. . Я люблю взвешенные средние. Взять и усреднить предсказания моделей по весам. И там уже смотреть какая моделька лучше сработает
  8. Михаил Монашев месяц назад
    Когда ещё ничего не записали можно что-то уже успеть прочитать, например, конфиг. И по скорости чтения прикинуть скорость записи. Коэффициент перевода одной скорости в другую в начале можно взять за 1, а потом использовать расчётный на основании прошлых запусков.
    • Kostja Osipov месяц назад
      Скорость чтения и записи не линейно зависит от объёма. На основании конфига экстраполировать нельзя
  9. Михаил Монашев месяц назад
    Чтобы постоянно поддерживать информацию о скорости записи можно имитировать эту самую запись, если диск не жалко конечно. Т.е. пишем постоянно, но или какую-то туфту или реальные данные.
  10. Михаил Монашев месяц назад
    А кто-то ещё на диск пишет или твой процесс единственный писатель?
    • Kostja Osipov месяц назад
      Не знаю
  11. Михаил Монашев месяц назад
    Вообще, если подумать, то нужные данные есть где-то в потрохах ОС и файлухи. Можно попытаться их от туда достать.
  12. Альберт Галимов месяц назад
    Собственно а какая цель? Зачем нужна инфа о скорости диска? Для шедулинга? Для предсказания времени операции? Еще для чего-то?
    • Kostja Osipov месяц назад
      Для того, чтобы избежать скачков в latency на запись. Для этого нужно уметь предсказывать время, которое уйдёт на разгребание очереди на запись, чтобы очередь не переполнять.
  13. Alex Tutubalin месяц назад
    Я не понял, вот честно"Правдивый прогресс-бар" так и надо рисовать, правдиво. Записал 10% - отобразил 10%
    • Альберт Галимов месяц назад
      Ага, на 99% сказал fsync() и получается прогрессбар как у продуктов майкрософт)
    • Alex Tutubalin месяц назад
      Не ага, а другая запись. Потому что писать стали, внезапно, иначе.
    • Andreenko Artem месяц назад
      DirectIO?
    • Alex Tutubalin месяц назад
      Да хоть что.Внизу лежит SSD-шка у которой стертых блоков недостаточно для всей записи.По первым байтам все будет ОК, а потом - нет.
    • Andreenko Artem месяц назад
      Ну контроллер SSD все таки консистентная штука. Поэтому при окончании таких блоков запись и начинает тормозить.
    • Alex Tutubalin месяц назад
      Но спросить его "сколько свободно" - нельзя.А было бы и можно - мы не знаем, сколько другие приложения пишут одновременно с нами.
  14. Iurii Krasnoshchok месяц назад
    Извини за оффтопик, но я бы не решал проблему администрирования в приложении. Просто потому что надёжного решения не существует, а "на глазок" может навредить больше. В данном случае создать backpressure, чтобы по памяти не взрываться - это хорошее решение. Опять же, база тупит из-за IO - это понятная проблема эксплуатации.
    • Kostja Osipov месяц назад
      Michael Monashev Зависит от нагрузки на базу. Если у тебя объём новых вставок - 3 МБ в секунду, объём памяти - 1 ГБ, а скорость записи на диск - 10 МБ в секунду, то ты в целом можешь тупо держать 100 мегабайт свободными и система никогда не затупит. Но если соотношения чисел другие, то затуп возможен. Сейчас там всё на эвристиках, исходящих из неких сакральных знаний, хочется это всё выпилить.
  15. Алексей Кудряшов месяц назад
    дельта производных по времени, минус локальные экстремумы. типа отсечки по квадратичному отклонению.
  16. Марко Кевац месяц назад
    Записать тестовый файл и замерить скорость.
    • Kostja Osipov месяц назад
      представь mod_php на каждом старте будет тестовый файл писать. ужасный user experience
  17. Илья Есин месяц назад
    Скажу, скорее всего, очевидную мысль:1. Писать чанками фиксированной длины2. Первые несколько чанков с O_DIRECT или fsync3. Для фиксации прогресса по первым чанкам скорость считать == 75МБайт/сек (консумерский ноутбучный шпиндель)4. Пересчёт исходя из полученных цифр, беря в расчёт наихудший вариант -5%.
    • Илья Есин месяц назад
      Ну и да, fsync читать как fdatasync.Перерасчет производить при каждой записи, ориентируясь на длительность f(data)sync, длину очереди на запись (если доступна).
  18. Денис Габайдулин месяц назад
    Очень интересная задача. Про константу предложили. Можно ее вынести в конфиг, написать значения для разных типов: hdd, ssd, nvme и т.д. А потом калибровать. Или начинать консервативно, с небольшого размера очереди и понемногу увеличивать. Но параметр имхо лучше, потому что люди которые используют базы данных не дураки, смогут подкрутить под железо.
  19. Антон Герасимов месяц назад
    В общем случае, для юзерспейса решения этой задачи нет. В ядре, можно написать свой дисковый планировщик, учитывающий патерн нагрузки и конфигурацию дисковой подсистемы.
  20. Виктор Комаров месяц назад
    наделать сэмплов открытых данных о состоянии системы (параметры диска, процессы etc) + фактической скорости записи и натренировать на этом xgboost например 😃
  21. Владислав Ярмак месяц назад
    Вы же понимаете, что итоговое время записи всех данных является случайной величиной, зависящей от (но не определяемой однозначно) от нагрузки на диски, их конфигурации (программной и аппаратной), разбиения данных по порциям и состояния кэшей. Здесь много неизвестных и почти нет линейных связей. Даже на продолжительном интервале времени средняя скорость может не иметь практического смысла из-за плавания суточной нагрузки.

Добавить ответ:
Отменить.