Нет, если потребляемое ОЗУ растёт линейно от кол-ва пользователей, то это нормально только для какого-нибудь кеша или in-memory БД, но там есть свои приёмы, чтобы ограничить потребляемую память сверху.
А для основного приложения — это совсем ненормально… Какой-нибудь reddit-эффект и у вас серваки вылетят с out of memory?
Ох, как Вас бомбит, даже ссылку на официальные system requirements заминусовали… ну и ну.
Не описания, а описания и выполнения. И да, процессы тоже жрут память.
Ну, если у них бизнес-процессы выполняются в том же процессе, что и IDE, то это не монолит виноват, это уже фантасмагория какая-то.
Намекаю: если вы чего-то в жизни не видели, это не значит, что этого не бывает.
А я и не спорю, что бывает. Но когда такое бывает, всегда можно улучшить и привести систему в более адекватное состояние, было бы желание и ресурсы.
Если в рекомендациях у IBM что-то написано — это не значит, что этому нужно верить.
Вот как! То есть Вы считаете, что когда разработчик заявляет, что для оптимальной работы его системы требуется N памяти (где N — это дофига Gb), а по факту система потребляет 4*N, то это адекватная работа системы? IBM слишком высокомерна по отношению к своим пользователям, примерно как Вы — к собеседникам )
For 64-bit systems, the minimum system memory requirement to support a clustered configuration with a deployment manager, node agent, and single cluster member is 6 GB. However, for optimal performance the recommended configuration is 8 GB.
Даже исходя из этого, можно сделать вывод, что у вас скорее был какой-то баг с утечкой памяти...
В классических клиент-серверных приложениях все эти микросервисы 10 лет назад уже были, может ещё и раньше были… чего тут обсуждать то? Или Вы их теперь через Docker стали разворачивать? xD
видел веб-приложения, которые совершенно по делу жрут 32 гигабайта и более — самый яркий пример это пожалуй IBM BPM. Всего-то на 50 пользователей, примерно.
Судя по описанию, какая-то web-IDE для описания бизнес-процессов. Хз как она умудряется столько памяти жрать… Интерфейс весь (сохранение взаимного расположения, drag-n-drop, etc.) можно на клиенте отрабатывать, к серверу запросы только при явном сохранении или авто-сохранение раз в минуту, плюс подгрузка запрашиваемых данных в JSON.
Я даже демо-видео посмотрел ради интереса и в упор не вижу с чего бы воркеру этой штуки хотя бы 1 Gb по делу съесть, не то что 32. Просто это IBM и им наплевать сколько вам придётся памяти докупить xD
Как правило, всё это добро сводится к запуску фоновых задач посредством того же монолита. Поэтому его сетап сводится к переносу crontab, если само приложение его не заполняет автоматически.
А если парсер прайса и ресайзер картинок — это отдельные приложения, то это уже и не монолит по сути.
В статье только аббревиатура HTTP встречается 6 раз, не считая множества других признаков… Так что уместнее вопрос, с чего Вы взяли, что тут обсуждается что-то кроме веб-приложений?
Монолит жрет 16Gb памяти. Микросервис, который точка отказа — 128Mb.
Это что ж Вы такое делаете? Обычно 500 Mb под инстанс монолита более, чем хватает.
Хоть числа и только как пример, но их соотношение вызывает вопросы… На микросервис конечно меньше памяти приходится, но во-первых не в 100 с лишним раз, а раз в 5-10, да и сумма памяти, потребляемой всеми микросервисами скорее всего будет в пару раз больше, чем нужно монолиту.
У меня сложилось впечатление, что Fesor имеет представление о том как происходит аллокация памяти. Чего не знают обычно пользователи скриптовых и языков с динамической типизацией.
Очень самокритично )
Так и быть, просвещу Вас: в Java строки иммутабельны и вместо конкатенации по факту происходит создание новой строки, поэтому Ваш пассаж про непрерывный блок памяти вообще мимо кассы.
Тут смысл именно сравнить str += 's' и $str .= 's', как эквивалентные операции. А после того, как выяснили, что конкатенация строк в Java медленная, надо задавать себе правильные вопросы, например: "а почему она медленная?". И разумеется, глупо отвечать "потому что в Java кривое управление памятью"… вообще никогда не списывайте на то, что язык плох. Языки пишут отнюдь не идиоты, кроме того в их разработку вкладываются огромные средства. Поэтому не бывает что-то медленно без причины, это всегда следствие определенных компромиссов, которые дают другие преимущества.
Смысл есть от любых сравнений. Если сравнивать скорость конкатенации строк, то можно узнать, что в Java она медленная. А перфоманс языка надо уже на более сложных алгоритмах смотреть, но там каждый тест должен эксперт по конкретному языку писать, а не так, как это обычно бывает в интернете )))
Обычно при сравнении производительности просто пишут эквивалентный код на разных языках, цели написать его оптимально при этом нет, скорее наоборот. Поэтому StringBuilder применять в данной случае нельзя, т.к. автор поставил задачу замерить именно скорость "ада и содомии по созданию строк".
А то Вы такими темпами второй тест редуцируете до строчки count = 1000000 и так далее.
В общем, сравнения должны быть честными, вне зависимости от того, что сравнивается.
Попробуйте поставить -t равным кол-ву ядер на сервере, и плавно снижать -c, пока не влезет.
Главное, время выполнения оставьте, а то ваш вариант теста в течении 300 миллисекунд вообще не отражает реальность.
P.S. И wrk не с сервера запускайте, а с локального компа.
1000 запросов в 1000 потоков через ab в качестве нагрузочного тестирования? Вы серьёзно?
Запустите нормальный нагрузочный тест, что-нибудь типа: wrk -t 4 -c 100 -d30s --timeout 2000 http://127.0.0.1:8080
Ну, в следующий раз задействую… Пока методом научного тыка я запомнил главных злодеев (которые слабенький комп могут превратить в неюзабельный кусок железа): BITS, Windows Defender, SuperFetch, Windows Update, Windows Search.
Я виндой уже давно не пользуюсь, это друзья просят помочь периодически. Одну тормозящую в текущий момент службу им отключишь, так через пару дней уже что-то другое снова диск убивать начинает. В общем, ппц какой-то.
Вообще, в 10-й винде нормальный мониторинг ресурсов из коробки, но не всегда показывает конкретную службу, бывает просто System пишет и всё.
По-моему самый "забавный" нюанс Win 10 — это 100% нагрузка на диск, причём это может быть и защитник Windows или какая-нибудь фоновая интеллектуальная служба передачи или ещё какая-нибудь ересь. Не понимаю, как MS смогла так накосячить с системными службами. Интересно, есть где-нибудь полный список того, что надо отключить, чтобы винда оставила диск в покое?
Нет, если потребляемое ОЗУ растёт линейно от кол-ва пользователей, то это нормально только для какого-нибудь кеша или in-memory БД, но там есть свои приёмы, чтобы ограничить потребляемую память сверху.
А для основного приложения — это совсем ненормально… Какой-нибудь reddit-эффект и у вас серваки вылетят с out of memory?
Сейчас чего только нет поверх JS, уверен, что и Forth найдётся...
Есть ведь уже Amber:
Наслаждайтесь ;-)
Ох, как Вас бомбит, даже ссылку на официальные system requirements заминусовали… ну и ну.
Ну, если у них бизнес-процессы выполняются в том же процессе, что и IDE, то это не монолит виноват, это уже фантасмагория какая-то.
А я и не спорю, что бывает. Но когда такое бывает, всегда можно улучшить и привести систему в более адекватное состояние, было бы желание и ресурсы.
Вот как! То есть Вы считаете, что когда разработчик заявляет, что для оптимальной работы его системы требуется N памяти (где N — это дофига Gb), а по факту система потребляет 4*N, то это адекватная работа системы? IBM слишком высокомерна по отношению к своим пользователям, примерно как Вы — к собеседникам )
Кстати, посмотрел требования к IBM BPM Advanced 8.5.7
Даже исходя из этого, можно сделать вывод, что у вас скорее был какой-то баг с утечкой памяти...
В классических клиент-серверных приложениях все эти микросервисы 10 лет назад уже были, может ещё и раньше были… чего тут обсуждать то? Или Вы их теперь через Docker стали разворачивать? xD
Судя по описанию, какая-то web-IDE для описания бизнес-процессов. Хз как она умудряется столько памяти жрать… Интерфейс весь (сохранение взаимного расположения, drag-n-drop, etc.) можно на клиенте отрабатывать, к серверу запросы только при явном сохранении или авто-сохранение раз в минуту, плюс подгрузка запрашиваемых данных в JSON.
Я даже демо-видео посмотрел ради интереса и в упор не вижу с чего бы воркеру этой штуки хотя бы 1 Gb по делу съесть, не то что 32. Просто это IBM и им наплевать сколько вам придётся памяти докупить xD
Как правило, всё это добро сводится к запуску фоновых задач посредством того же монолита. Поэтому его сетап сводится к переносу crontab, если само приложение его не заполняет автоматически.
А если парсер прайса и ресайзер картинок — это отдельные приложения, то это уже и не монолит по сути.
В статье только аббревиатура HTTP встречается 6 раз, не считая множества других признаков… Так что уместнее вопрос, с чего Вы взяли, что тут обсуждается что-то кроме веб-приложений?
У Вас, видимо, есть несколько примеров веб-приложений, которые могут по делу откушать 16 Gb оперативки?
Это что ж Вы такое делаете? Обычно 500 Mb под инстанс монолита более, чем хватает.
Хоть числа и только как пример, но их соотношение вызывает вопросы… На микросервис конечно меньше памяти приходится, но во-первых не в 100 с лишним раз, а раз в 5-10, да и сумма памяти, потребляемой всеми микросервисами скорее всего будет в пару раз больше, чем нужно монолиту.
Очень самокритично )
Так и быть, просвещу Вас: в Java строки иммутабельны и вместо конкатенации по факту происходит создание новой строки, поэтому Ваш пассаж про непрерывный блок памяти вообще мимо кассы.
Вы ветку комментариев то читаете или к чему Ваш комментарий? Про кривое управление памятью Fesor писал двумя сообщениями выше.
Тут смысл именно сравнить
str += 's'и$str .= 's', как эквивалентные операции. А после того, как выяснили, что конкатенация строк в Java медленная, надо задавать себе правильные вопросы, например: "а почему она медленная?". И разумеется, глупо отвечать "потому что в Java кривое управление памятью"… вообще никогда не списывайте на то, что язык плох. Языки пишут отнюдь не идиоты, кроме того в их разработку вкладываются огромные средства. Поэтому не бывает что-то медленно без причины, это всегда следствие определенных компромиссов, которые дают другие преимущества.Смысл есть от любых сравнений. Если сравнивать скорость конкатенации строк, то можно узнать, что в Java она медленная. А перфоманс языка надо уже на более сложных алгоритмах смотреть, но там каждый тест должен эксперт по конкретному языку писать, а не так, как это обычно бывает в интернете )))
Обычно при сравнении производительности просто пишут эквивалентный код на разных языках, цели написать его оптимально при этом нет, скорее наоборот. Поэтому StringBuilder применять в данной случае нельзя, т.к. автор поставил задачу замерить именно скорость "ада и содомии по созданию строк".
А то Вы такими темпами второй тест редуцируете до строчки
count = 1000000и так далее.В общем, сравнения должны быть честными, вне зависимости от того, что сравнивается.
Попробуйте поставить -t равным кол-ву ядер на сервере, и плавно снижать -c, пока не влезет.
Главное, время выполнения оставьте, а то ваш вариант теста в течении 300 миллисекунд вообще не отражает реальность.
P.S. И wrk не с сервера запускайте, а с локального компа.
1000 запросов в 1000 потоков через ab в качестве нагрузочного тестирования? Вы серьёзно?
Запустите нормальный нагрузочный тест, что-нибудь типа:
wrk -t 4 -c 100 -d30s --timeout 2000 http://127.0.0.1:8080Ну, в следующий раз задействую… Пока методом научного тыка я запомнил главных злодеев (которые слабенький комп могут превратить в неюзабельный кусок железа): BITS, Windows Defender, SuperFetch, Windows Update, Windows Search.
Я виндой уже давно не пользуюсь, это друзья просят помочь периодически. Одну тормозящую в текущий момент службу им отключишь, так через пару дней уже что-то другое снова диск убивать начинает. В общем, ппц какой-то.
Вообще, в 10-й винде нормальный мониторинг ресурсов из коробки, но не всегда показывает конкретную службу, бывает просто System пишет и всё.
По-моему самый "забавный" нюанс Win 10 — это 100% нагрузка на диск, причём это может быть и защитник Windows или какая-нибудь фоновая интеллектуальная служба передачи или ещё какая-нибудь ересь. Не понимаю, как MS смогла так накосячить с системными службами. Интересно, есть где-нибудь полный список того, что надо отключить, чтобы винда оставила диск в покое?