Since i got into optimizing sql a bit - i've started watching how exactly many disk writes does it do and how soon will it destroy my SSD.
Раз уж я полез в оптимизацию sql - я начал следить за числом операций записи на диск, и мне стало интересно, как быстро оно убъет мой ССД
I had it running for more than a week at the load around 1750 tasks per hour constantly spawning, going through some processing and dying, and got 4610.5 writes per hour on my ext4 1TB SSD, which will result in writes equivalent to 20.6 TB/year. Which is not that bad, considering my idle (nothing runs in the system except browser) writes are about 6.5 TB/year.
Шедулер работал более недели без остановки, обрабатывая 1750 тасков в час, которые постоянно рождались, совершали некоторую работу на рабочих и умирали. в таком сценарии у меня вышло в среднем 4610.5 записей в час, на ext4 1TB ССД, что (учитывая все дефолтные настройки фс и диска) эквивалентно записи 20.6 TB в год. Не так уж плохо, учитывая, что система без нагрузки, только с броузером, так сказать в холостом режиме, выполняет записей на порядка 6.5 TB в год.
So with TBW of 300 as state in specifications this kind of load would ruin my SSD in 14.5 years, instead of 46 years in idle usage.
С TBW для моего ССД в 300 (согласно спецификации) - такая постоянная нагрузка убъет мой ССД через 14.5 лет, вместо 46 лет в холостом режиме.
Is it bad? hard to say - 1750 abstract tasks per abstract hour sure sounds like a lot... of abstractness. To give you a real life estimation: to render 100 frames you would probably create a network that would start with 1 task, split it into blocks by framerange say into 10, create an individual task for each frame - so ~111 tasks to render 100 frames.
Насколько это плохо? сложно сказать - 1750 абстрактных тасков в абстрактный час - это абстрактно. Да, звучит как достаточно много. Для примера, задача по рендеру 100 кадров с более-менее разумным сетапом в сумме создаст: 1 начальный таск, таски по разделению фрейм ренджа, например, на 10 фреймов каждый, и по индивидуальному таску на кадр. В итоге - 111 тасков для рендера 100 кадров.
how does it scale? even harder to say - all depends on node network and designed average task lifetime - the longer task's invocation is being calculated by worker (simulation, render, scene creation, etc - all long tasks you would want to do on farm) - the less strain there is on scheduler's hardware
Как поведет себя система при увеличении масштаба? сказать еще сложнее: все зависит от шедулер графов, среднего времени жизни таска, как долго таски обрабатываются шедулером по сравнению со временем их вычисления на рабочих: чем дольше таск считается на рабочем - тем меньше нагрузки в это время на шедулер, так как он в это время не делает ничего с этим таском, кроме как ждёт его завершения.
so at this point i cannot reasonably estimate what would be the real load even on a small studio? or just one freelancer
There's just too many variables to be comparing things just by tasks per time
Я бы хотел как-то оценить нагрузку для маленькой студии, или хотя бы
для загруженного фрилансера (или группы в пару фрилансеров), но не могу - слишком много неизвестных.
Anyway, for personal use the sqlite database can always be copied to tmpfs, like in /dev/shm, to work, and copied back when work is done, though it looses all benefits of sqlite database's crash resilience.
Но если уж на то пошло - для персонального пользования база данных может просто работать в tmpfs, например в /dev/shm, а по завершении копироваться назад на диск. Хотя в такой схеме теряется вся суть sqlite базы данных, постоянно поддерживающей корректное состояние базы данных на диске, устойчивая и к крашам софта, и к отключению электричества.
And what about HDD you ask? HDD is much slower in terms of write speed, and especially random disk writes. Even though sqlite engine in does try to sort writes within small batches when written to disk, the speed is still up to 10 times slower, which especially shows when hundreds and thousands of tasks are processed in a second. You think you will never have 100 tasks per second? just one task spawning 100 per frame tasks at one moment gives you a burst of 100 tasks that are going to be processed at the same time, and here you will have that slowdown.
А что насчет механических дисков? Механические жесткие диски значительно медленнее в плане записи, особенно в произвольном порядке. Несмотря на то, что драйвер sqlite пытается накапливать и сортировать записи в рамках транзакции, чтобы ускорить работу на последовательных механических дисках - все равно скорость работы бд до 10 раз медленнее, что становится особенно заметно на сотнях и тысячах обработках тасков в секунду. Но если вы думаете, что 1000 тасков в секунду у вас никогда не будет, то смотрите: 1 таск по рендеру порождает 100 тасков, по одному для каждого фрейма, и неожиданно у нас 100 тасков, которые будут обработанны одновременно. Да, это единовременный "всплеск", всреднем таких нагрузок, конечно, не будет, но на этом единовременном всплеске тасков и будут ощущаться замедления от скорости диска.
To mitigate that i've introduced similar transaction squashing (uniting) - similar transactions, like ones that just change task's state or node, are united into one if happen within like 0.25 seconds. This helps significantly on bursts of tasks, like when hundred of tasks are just being generated (ex. when ifd task is generating individual frame tasks). So it's totally viable to run small/medium load of tasks.
Чтобы избежать этого я добавил механизм объединения схожих транзакций. Независимые транзакции одной природы могут объединяться в одну транзакцию, если они происходят в определённом временнОм окне, например 0.25 секунды. Этот механизм позволяет значительно снизить число транзакций для описанных всплесков, тем самым позволяя драйверу sqlite лучше соптимизировать последовательные записи на диск в рамках этой одной большой транзакции, что значительно увеличивает скорость работы базы данных в описанных ситуациях. Так что на механических жестких дисках вполне возможно работать с небольшой/средней нагрузкой.
This note was supposed to be posted a month ago, and i only now noticed it's not actually published...
Мда... хотел запостить это с месяц назад, и только сейчас заметил, что пост всё еще в черновиках...