Иван Шумов, все может быть... у меня недавно тоже проект был по распределенным вычислениям, там тоже параметры формул динамические и на каждом из узлов они должны актуализироваться, решил через очереди + редис + БД на случай непредвиденных обстоятельств... в принципе работает без проблем, обрабатывает спокойно порядка тысячи "вычислительных потоков" в секунду в штатном режиме, не пиковом...
Алексей Николаев, да копать-то некуда, причем без шуток... Когда модуль был запущен и выжрал 40% проца, мы немного офигели от такой его "наглости". Через отладчик попробовали отпрофайлить - безрезультатно, вызовы всех функций занимали крайне малое количество времени на выполнение, а вот вызовы методов из системного модуля timer.js (или time.js - точно не помню) как раз кушали гораздо больше. Мы начали сначала просто пытаться отключить вызовы всех блоков от полного процесса, пока не вышли на ситуацию, что остался активным только основной код самого процесса и вот этот модуль, т.к. он является критическим. В основном коде вызовов таймеров не было, а в модуле изначально был setInterval() ... закомментили его вызов - нагрузка на проц сразу ушла... Заменили на setTimeout() - загрузка проца не повысилась... вернули в работу все остальные части кода - никаких проблем...
Снова вернули setInteval() - опять проц в пике... Так что просто заменили на setTimeout - но мне чисто для себя стало очень интересно - почему такая фигня в Node v10
я понял о чем Вы, но нет... примерный вывод в обоих враиантах выглядит примерно так (размерность числа, конечно с потолка, главное разница между ними - она же периодичность срабатывания):
т.е. разница между числами в районе заданных 1000мс, если бы вызовов было больше - т.е. не 60 в минуту, а 120, то и разница в числах имела хотя бы местами меньшую разницу (например около 500мс)...
сейчас уже не за рабочим кодом, но там все просто (могу чуть с синтаксисом ошибиться) там в класс обернут весь модуль, я для понимания оформил вопрос в формате функций (думаю, по сути разницы никакой функция или метод класса)...
let fdata = false;
const path = '.....';
... тут всякоразно ...
periodicFunction() {
... тут setTimeout() ...
FS.readFile(path, (err, data) => {
if (!err && data) {
fdata = JSON.parse(data);
};
});
};
Частоту я проверил сразу же - в обоих вариантах отличия в пределех 10мс... от 997 до 1005 мс... Эти доли можно списать на погрешность вывода ( проверял с помощью console.info(Date.now()) ), к тому же отклонения от заданных 1000мс присутсвуют в обоих вариантах, просто в setInterval они меньше...
Еще раз спасибо за наводку.
Не кривя душой, в сравнении с монгой скорость вставки ниже примерно на 40% (на одном инстансе логгера удалось добиться скорости вставки около 60тыс в сек, против 100тыс в сек на Монго). Может быть если покрутить настройки, получится и увеличить данный показатель, но в принципе это уже перекрывает наши запросы.
Выборки делаются быстро и четко, партиции сделали посуточные, так что даже не придется хранить лишнее дольше, чем это нужно.
Единственное, что смущает - это подъедание памяти сравнимое с Монгой. Но тут сложно сравнивать - ибо и CH и MDB на одной машине крутятся и монго по идее должна есть все, что может, освобождая то, что просит система... в общем тут сложнее - надо будет покурить мануалы и может помучать самих яндексоидов на тему ограничений в параметрах запуска сервиса.
Еще раз СПАСИБО!
PS. Поправочка. На сервере скорость вставки в один поток из одного инстанса при приеме данных через UNIX-сокет достигла 80тыс в сек. Этого более чем достаточно для работы!!!
Посмотрел аранго - крайне сомневаюсь в его подходимости:
- работать с ним через HTTP вместо поддержки постоянного коннекта
- так и не нашел возможности вставки записей блоками
Может он и держит большое кол-во данных и умеет нечто схожее с SQL, но для высокоскоростного наполнения данными там какой-то треш...
Но спасибо в любом случае, теперь знаю еще одну БД.
Philipp, Вы правильно говорите, что никто не сможет это прочесть, но это уже такой нюанс, который решается нюансами ГУИ. Простой вариант - это просто ведение счетчика, который считает полученные для отображения записи и в случае превышения, скажем, 100 в секунду, стопит отображение и выдает предупреждение о слишком общих условиях выборки для реалтайм вывода.
Но по факту - нужна возможность, это один из базовых критериев, который нельзя пересмотреть.
chupasaurus, Если это вопрос ко мне, то нет =)))
Мы пока изучаем решение от Яндекса и его возможности (и возможности работы с системой под наши хотелки).
ELK смотрели, GrayLog тоже и еще ряд уже готовых "из коробки" систем лог-менеджмента. Но они не совсем устраивают своими возможностями. Точнее даже сказать, у них у каждой есть что-то нужное, но в совокупности ни у одной =(
К тому же помимо менеджмента логов в обычном понимании, нам нужна возможность читать логи "реалтайм" хотя бы по простейшим фильтрам (проект/сервер/тип событий) + отображать в минифреймах текущую информацию о каждом из проектов (которую каждый проект постоянно сообщает о себе)
Дмитрий Беляев, ага, это уже почитал и понял.
В принципе:
- логи апдейтить не надо, так что не страшно
- интерес к логам пропадает через недельки две, а как я понял, есть удаление партициями месячными, ну в принципе не критично, если старые полежат в базе на пару недель дольше
- по поводу инсертов, там простая как кирпич саморегуляция - пришел пакет данных, выполняется вставка, пока не вернулся колбек о результатах новая порция копится (конечно есть и тайминг на случай отвала БД и страховка), как пришел ответ от базы о завершении операции кидается весь следующий накопленный в буфере кусок. В пиковые нагрузки такие "пакеты" могут быть по 15-20 тыс записей, в среднем они (пока для Монги получается) около 5-6 тыс в команде
sim3x, так потому и появилась необходимость базы и всего остального, что появилась серьезная необходимость читать/анализировать логи, причем как разных модулей раздельно, так и в совокупности сквозной сортировкой по времени. Так что текстовики - это пройденный этап.
sim3x,
0. частично структурированную: несколько полей обязательных, строковые данные + одно поле JSON-строки (на текущий момент в монго все летит как один объект)
1. сейчас в Монго все летит как объекты
2. обработка для записи сейчас не требуется, т.к. передаются уже сформированные клиентами объекты, проверяются только обязательные "поля - свойства"
3. по выборкам пока предсказать сложно, но что точно будет - это запрос логов за какой-то интервал времени с фильтрацией по обязательным полям и сортировкой по времени, и наверняка будет еще просто поиск по подстроке в свободном поле данных
4. как минимум около 20тыс в сек входящих данных, с пиковым пределом около 50тыс в сек (но это будет крайне редко, только в случае падения подключенных систем)
asd111, Вы полагаете, что это из-за пользователей и их жалоб? Отнюдь...
1. Если компания ставит в качестве внутреннего порядка использование *nix - это регламент, с которым должны соглашаться пользователи, нравится им это или нет. И давайте смотреть правде в глаза - человек привыкает ко всему, а молодежь еще и вполне быстро.
2. Если после попытки перейти на *nix компания и возвращается на Win - это в подавляющем большинстве связано не с юзерами, а с отсуствием дешевого специалиста по никсам. Дешевых неплохих виндузятников дофига + система распределения прав в винде с ее доменной структурой дает больше гибкости, чем никсовые "примитивы".
3. Опять же финансовая составляющая, если компания "теневая" в плане чистоты ПО, то им естественно пофигу, какие там пиратки накатил их админ. А с учетом пп.1 и 2 это удобнее и дешевле. А вот когда речь идет о большом количестве систем, то период использования *nix может использоваться для накопления затрат на лицензионный софт.
Но в целом, соглашусь с Вами - большинство компаний, попробовавших *nix на рабочих местах возвращаются на Винду, но не по причине нытья ленивых юзеров ;)
ЗЫ. К слову, я перешел по личному желанию с винды на дебиан. В силу гораздо больше удобства работы - лучше совместимость, больше свободы действий, работает пошустрее да и вообще, глюки и обновы 10-ки уже задолбали. Вечно как обнова, так что-то ломается и надо чинить ...
Вот тут с Вами крайне не соглашусь. Знаю немало компаний, которые на пользовательских машинах ввели никсы в ранг "штатная операционка". Да, кастомизация и привыкание заняли некоторое время, но...
- вместо опенОфиса использовали Либерти (он более близок по интерфейсу к МС офису)
- основной рабочий спец. софт (1С в частности) крутится так же как у ТС на выделенном сервере (это, к слову и быстрее, чем работать с базами по сети, даже если используется SQL-вариант)
- скриптование рабочих станций в никсах гораздо более гибкое
Просто суть в том, что это должна быть именно политика на уровне компании, а не инициатива IT-шника. В первую очередь это экономит средства компании на лицензии - которые довольно ощутимы при штате в 100-200 рабочих станций. Во вторых - ОООЧЕНЬ сильно снижает возможность подцепить какую-то вирусную дрянь из писем сотрудниками (а если еще и заморочиться неизменяемой конфигурацией - то после ребута все, что юзер и умудрится схватить и запустить под своими правами, уйдет в лес)..
Так что зря Вы так - в конце концов не компания должна подстраиваться под юзера. Сотрудник приходит - ему озвучивают условия труда (компы на никсах, работаем на терминале и баста), а дальше если согласился, нефиг потом трыздеть, что неудобно!
Разбивать очень геморно и реально неудобно, т.к. тамих блоков несколько на самом деле, плодить кучу файлов тоже не лучший вариант и параметров запуска гораздо больше - я только ключевое отличие показал для наглядности.
За ссылку спасибо огромное - я читал, судя по линку на странице Вашей ссылки (справа внизу) обновленную доку - ведет сюда https://pm2.io/doc/en/runtime/guide/ecosystem-file/
Вот там про команду "pm2 reload ..." нет ничего.
Еще раз спасибо - проверил, работает вполне комфортно (только удаленные приходится убивать вручную, но это всяко лучше, чем стопать всю группу)