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 в год. Не так уж плохо, учитывая, что система
Posts
The problems stated in update #8 were all solved surprisingly fast Graph layout - solved (for now) with grandalf - a fun little module solving most of layouting problems with it's Sugiyama Layout. There is a problem though - nodes of grandalf do not care about the order of output edges, but my node editor does care, so generated output edges may intersect. not a huge problem for now, will leave it for the future me. Лэйаут графа нод - решено (на пока что) grandalf -ом - маленький лёгкий модуль, решающий все мои текущие проблемы своим лейаутом Сигуямы. Единственная проблема - ноды в grandalf не имеют порядка рёбер, но ноды в моём графе имеют строго сортированные входы-выходы, так что в результате лейаута эджи могут пересекаться. Basic resouce management - you can set cpu and ram requirements, that's the most basic, good for now, doesn't matter at all if you run it locally Базовый менеджмент ресурсов реализован - инвокации могут задавать требования к числу процессоров, к ра
I think an updated system overview is long past due. Думаю давно следовало сделать небольшое овервью Taskflow name is temporary, as it turned out there is a library named taskflow also dealing with distributed task management... So that will be changed before first public release. Well, i should have done a better name research beforehand. Имя Таскфлоу оказалось уже занято библиотекой со схожей областью... Придется придумать новое имя перед релизом. Чтож, надо было лучше исследовать вопрос заранее. "Taskflow" consists of 3 major components: scheduler, worker and viewer. All 3 are currently parts of the same package. However since viewer requires much more heavy GUI dependencies - it makes sense to separate it into it's own package "Таскфлоу" состоит из 3х компонент: шедулер, рабочий и вьюер. Все 3 - часть одного питон пакеджа. Однако учитывая, что вьюер тянет тонну тяжелых интерфейсных зависимостей - имеет смысл его выделить в отдельный пакедж Component names s
Continuing the node writing topic. So last time i showed how easy it is to define the interface of a node, now let's take a look at a whole node. Продолжая тему написания нод. Прошлый раз я продемонстрировал простой АПИ для создания интерфейса ноды, теперь же давайте посмотрим на написание ноды целиком It will be a simple node that just creates a file with given name and and writes one of task's attributes there. Для примера сделаем ноду, которая банально записывает значение атрибута таска в файл, путь которого берется из параметра ноды first we just need to subclass the BaseNode class Начнём с наследования класса BaseNode class LogSomeAttribute(BaseNode): def __init__(self, name): super().__init__(name) Now we initialize interface, as we might remember from previous post Инициализируем интерфейс, как в прошлом посте ui = self.get_ui() with ui.initializing_interface_lock(): ui.add_parameter('where to write', 'Log File Path'
It has been quite some time since last update. I've been slowly polishing things here and there in my free time. Давненько я не постил обновлений. Все это время я медленно допиливал всякие мелочи и не очень, в свободное время по вечерам. My plans of making an pre-alpha version public have changed. I really don't think there is much people following this project at all, so there is no rush dropping this half working demos. Планы опубликовать пре-альфа демку изменились. Я подумал - тут и так максимум полтора человека интересуются этим проектом, и врядли полуработающая демка кого-то сейчас заинтересует. I will better make it actually usable, make it able to actually be used in work, and make some example workflows. There is no rush for anything. Я решил, что лучше я таки доведу альфу до полноценно рабочего состояния, сделаю примеров работы с системой, чтобы буквально можно было уже тестировать таскфлоу на своих реальных задачах. Не думаю, что стоит торопиться. Anyhow, in thi
In this update I want to describe some base concepts of synchronizing tasks. В этом апдейте я хочу рассказать о паре основополагающих концепций, связанных с синхронизацией тасков. In some cases we would want to hold tasks from moving forward before certain conditions are met, maybe even merge those tasks, or at least merge their attributes. В ряде случаев мы хотели бы ожидать определённого условия прежде, чем пропустить таски к следующей ноде, возможно даже объединив таски, или объединив их атрибуты. For example if we want to make a video file out of separate rendered frames: each rendered frame corresponds to one render task, so we need to be able to wait for all of renders for the same sequence in order to proceed to making a video out of them. Например, если мы хотим сделать видео превью из отрендеренных кадров: каждый отрендеренный кадр соответствует одному рендер таску, значит мы должны уметь ждать все кадры одной секвенции прежде, чем дать ход таску по созданию видео из этих кадр
Development goes slow but steady. Still working mainly on UI and user interaction workflow in general. Прогресс идёт медленно, но равномерно. Основная область работы - всё ещё интерфейс и взаимодействие юзера с вьюером вцелом. Finally node renaming is done! Also note a little change to the node's header - it now displays node type separately from the name Наконец-то можно переименовывать ноды! Так же заметьте изменение в хедере ноды - теперь тип ноды отображается независимо от имени, снизу справа Task status can be changed, task can be paused/unpaused - basically what you would expect from any other farm management software Состояние тасков можно менять, таск может быть приостановлен/продолжен - по сути самый стандартный функционал любого менеджера фермы Zooooooom! Зуууууууум! Tasks can have one or more groups. Groups are now selectable in the list to the left. Children tasks inherit groups from parents, so it's easy to filter out a task tree created by one specific task. Thi