так заявляют производители железа и ОС, а IBM может иметь свои взгляды на жизнь
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Загрузка процессора
- Автор темы ToxaRat
- Дата начала
Akupaka
А имеем мы то, что сервер домино лицензируется по ядрам, а эти самые ядра не используются по полной, даже порой можно кричать, что вообще не используются.
И твердить заказчику, что многоядерный сервер вас спасет уже сродни заведомо его обманывать на этот счёт.
Так что проблема как по мне весьма серьезная.
И я буд очень рад, если вдруг я не прав и мне подскажут как один таск можно таки по всем ядрам размазать и дейсвительно использовать многоядерность и динамическую разгрузку.
То, что вам "кажется" не имеет общего с тем что есть, тем более когда вы не знаете и даже не желаете узнать.
А имеем мы то, что сервер домино лицензируется по ядрам, а эти самые ядра не используются по полной, даже порой можно кричать, что вообще не используются.
И твердить заказчику, что многоядерный сервер вас спасет уже сродни заведомо его обманывать на этот счёт.
Так что проблема как по мне весьма серьезная.
И я буд очень рад, если вдруг я не прав и мне подскажут как один таск можно таки по всем ядрам размазать и дейсвительно использовать многоядерность и динамическую разгрузку.
слушай, хватит мне "выкать", я ж просил, кажется )
не понял... вначале ты вообще не об этом говорил
теперь о загрузке и лицензировании. ты же сам грил, что задачи распределяются меж ядрами. в чем тогда вопрос? )
агент не ограничен одним ядром, если он будет жрать ресурс проца, то система может распределить его выполнение на несколько ядер, благо уже умеет (винда с ХП сп 3 или 4, вроде, линуксы не знаю, думаю, что и раньше).
общение агента с базой и юзера с базой ограничены не кол-вом ядер, а скоростью обмена данными между хранилищем инфы и остальными участниками процесса передачи данных к их пользователю (агент, юзер). и процессор (хороший) уже не самое узкое место обычно.
аналогично и с индексером.
А _ты_ твердил? Ай яй яйToxaRat сказал(а):
Информация IBM и практика показывают что в ~90% случаев узким местом является дисковая подсистема серверов, как никак файл-серверное приложение Проблема высосана из пальца +1
. Таск по ядрам размазать нельзя, можно увеличить количество тех же индексеров что бы параллельные таски в очереди не стояли (но кардинально не спасет).З.Ы. Кстати sh stat platform гораздо интереснее в плане анализа использования ресурсов.
Constantin A Chervonenko
Green Team
В LND ЛЮБОЙ процесс ограничен одним ядром. Ускорить индексацию можно, запустив несколько индексёров (но не более, чем есть ядер/процессоров. См. Одминский хелп). Каждый пойдёт на своём ядре..
это не ускорит индексацию для одной базы, так как второй процесс её индексировать не сможет по определению - база уже индексируется
чувствуете? даже тут и то подвох.
нам рекомендуют больше ядер, больше процессов, но если у нас всего ОДНА база нам это никак не поможет вообще
кто тебе рекомендует больше ядер? кто тебя заставляет брать много ядер для одной базы? кто тебя вообще чего-то заставляет?
если у тебя всего одна база, ты зря потратил денег на лотус вообще! ))
Это откуда информация?
Вроде про деньги он ничего не говорил
puks
так что вывод тут весьма поучительный - не говорите своим, что установка нового многоядерного сервера существенно поможет, оно то поможет, но максимум на 20-30% в независимости от того во сколько раз ядер стало больше, те кто жаловался на работу своих баз и дальше будут так жаловаться
это и я показал выше и расписано в документации
так что вывод тут весьма поучительный - не говорите своим, что установка нового многоядерного сервера существенно поможет, оно то поможет, но максимум на 20-30% в независимости от того во сколько раз ядер стало больше, те кто жаловался на работу своих баз и дальше будут так жаловаться
Припоминается, что когда начиналась вся эта "многоядерность", то уже тогда вскользь проскакивала в статьях инфа, ещё пока теоретическая, что для БД (именно для индексирования) использовать многоядерность - выигрыш очень сомнительный. Позже HT это подтвердил своим провалом на базах данных снижением скорости, в среднем, на 20-30%; в сети были и более печальные случаи..
Хотя с другой стороны, по теории, длинная команда должна разделяться на более мелкие (каждая - на своём ядре) аппартно, и всем ядрам должно быть параллельно, что оно вообще делает, что базы индексирует, что в косынку играет.. т.к. ядро не должно знать что оно делает - в момент времени выполнило команду и отдало результат.
Мне кажется, что сделать можно было, но надо очень стараться.
Если на хотят стараться, то разделяли бы базы данных по ядрам (на 1 ядро - одну БД, а остальные - в очередь). Или на уровне вьюх - это было бы круче.
И индексер - не худший случай, - хоть одно ядро, но жрёт! Взять агент-манагер, так тот до 30% у меня никогда не доходил - тупик от количества доков наступает, но мощь всего ядра не используется. Увеличение мощности железяки влияет мало. Такое ощущение, что специально затык поставили, гады...
вот и мне кажется, что все дело не в ядрах и их кол-ве, а в реализации продукта.
Не все так страшно и попробую это доказать. Действительно - многоядерные системы повышают Общую производительность системы. Посмотри - что больше всего тормозит в Домино? Это строенные\недостроенные вьюшки\фтиндексы. А так же скажу точно что репликатор и кластерный репликатор. т.е. подсистема хранения данных.
Что бы не быть голословным -2 4-х ядерных HP DL380 в кластере. Настройки Домино по умолчанию. индексы большинства баз Update after first use. (согласно рекомендациям по снижению нагрузки на сервер
))около 80 баз с общим обьемом в 120-130гб мильонов 8-9 доков. 900 пользователей - постоянно около 500 коннектов на сервере,
Результат - дикие тормоза утром и периодически в течении дня. В таскменеджере - неравномерная загрузка процессоров.
Почесав репу и прочтя документацию - сделал следующее:
Updaters=8
UPDATE_FULLTEXT_THREAD=1
Replicators=4
ClusterReplicators=4
Во всех базах вьюшки переделали на автоматик.
Что наблюдаем в консоли - индексеры цепляется к одной базе и чешут разные вьюхи, а другом треде делается ФТ индекс. репликаторы стартуют дружно, кластер оч оперативно реагирует. А таскменеджер радует глаз слаженной работой ядер...
Если бы ядер было бы больше - то все это хозяйство крутилось бы шибче
)PS - ВСЕ агенты вынесены на перс. комп под видом сервера - и агенты там шуршат -не мешают основным серверам.
PPS - щас глянул 250 гиг баз и десятый миллион пошел...
Круто!Почесав репу и прочтя документацию - сделал следующее:
Updaters=8
UPDATE_FULLTEXT_THREAD=1
Replicators=4
ClusterReplicators=4
Во всех базах вьюшки переделали на автоматик.
Что наблюдаем в консоли - индексеры цепляется к одной базе и чешут разные вьюхи, а другом треде делается ФТ индекс. репликаторы стартуют дружно, кластер оч оперативно реагирует. А таскменеджер радует глаз слаженной работой ядер...
Если бы ядер было бы больше - то все это хозяйство крутилось бы шибче
PS - ВСЕ агенты вынесены на перс. комп под видом сервера - и агенты там шуршат -не мешают основным серверам.
А если без кластера, каков будет прирост производительности? Размазывается ли по ядрам также красиво?
P.S. А с ДАОСом, наверное, будет ещё красивше))
Не - ядра и кластер - это же из разных опер. Смысл в том, что Домино при большом количестве ядер не размазывает один таск по нескольким ядрам, а может несколько тасков разбросать по имеющимся ядрам.
Чудес на свете не бывает - иногда сервер проседает конкретно и в этом случае помогает кластер. Поскольку сервера в кластере проседают неравномерно - народ перескакивает на другой сервер... так и скачет туда сюда...
Можно конкретнее? Что и где в документации?
Кто-нибудь из обсуждающих имеет четкую информацию о реализации многопроцессорности или ее отсутствии в Домино?
Constantin A Chervonenko
Green Team
Разумеется.
Но 8-ми ядерный монстр ради единственной базы - это какое-то извращение, не находите?
Но и с одной базой лишние ядра/процессоры не совсем бесполезны: на одном - индексёр, на втором - репликатор, на 3-м - роутер.. Производительность вырастет, не в 3-4 раза конечно.
А если баз много, то там доп.процессоры дадут почти линейный прирост: таски расползутся по ядрам пропорционально потребностям
На счет индексера - если их несколько (Updaters=хх) они могут дружно накинутся и на одну одну базу...
будет конфликтная ситуация или они будут иметь "групповой" доступ к базе и аптейдить каждый свое? )
у меня была похожая ситуация, в консоли писало, что такой-то вид обновляется и еще один, но я так и не понял, что там на самом деле происходило.
Обучение наступательной кибербезопасности в игровой форме. Начать игру!