mayton....
Я месседж Димы понял так.

- Мы не можем наращивать производительность в одном слое архитектуры. Например
подтянули больше ядер процессоров - получили когерентность. Блокировки... спины.. стали
взымать с нас "дань" просто так. Просто подняли тактовую
частоту - надо поднимать и частоту системной шины и как следствие планок памяти и как
следствие HDD тоже должны быстрее отдавать отклики.

Я к этому пришел в нулевых, когда апгрейтил свой комп для игр.

Вроде же есть понятие "масштабируемость".

Если конкретная задача и конкретная алгоритм нормально масштабируется - добавили нужного ресурса, получили обещанный прирост производительности

Если не масштабируется, то хоть процессоров, хоть памятью, хоть дисками можно весь дом забить - быстрее работать не будет

И никак это ни с процессорами, ни со скоростью памяти не связано. Исключительно с задачей, используемым алгоритмом и кривизной рук архитектора/программиста.

IMHO

Dima T....Тормоза в 5-7 раз! Какой тюнинг компилятора это перекроет?
Я приводил реальную задачу, на реальном проекта

Прикладная система на конкретной железяке (Numa 2 core, 40 ядер) жестоко отжирала CPU. Настройками JVM (GC и JIT) потребление CPU снизилось в 3-4 раза. Куда уходило CPU - я не выяснил (да и не нафиг это не интересно), просто куда-то уходило, "в между модульное пространство". В данном случае, точнее "в между thread пространство".

Причину (особенности конфигурации продакшен сервера) и метод лечения (нужные ключи JVM) нашли, на этом разбирательство завершили.

P.S. Изначально грешили на низкую скорость ConcurrentLinkedList и чрезмерное обилие Atomic'ов в коде. Пытались оптимизировать код. Реальность оказалась проще ))) Шедулер потоков Linux и JVM, почему-то стал "не так" работать.

Вот честно, брать сорцы и разбираться "как же он на самом деле работает" - можно годами. Фиг какая фирма такие разбирательства в рабочее время и необходимое оборудование оплатит.

Mayton, IMHO теперь Вы начали поднимать "очень толстые темы"

mayton....Тот-же Oracle RAC Емнип больше 64-х узлов не строится.
Есть там сетевые проблемы....
Нет там сетевых проблем.
Там есть финансовые проблемы.

Если кто-то оплатил лицензии на Oracle EE на RAC на 64-х узлах... уверяю Вас... у него нет "сетевых проблем". Что бы под этим не подразумевалось. У него проблем ни с сетью, ни с автомобилем, ни с дачей - нет ))) По определению.

mayton...
Возьмите любую проблему из области баз данных там где мы работаем не с историческими
а с актуальными сведениями. И начинается. Шардинг. Партишининг. Это все не безплатно.

Что значит "не бесплатно"?

Если задача допускает партиционирование - в чем проблема?
Если же для задачи партиционирование, как собаке пятая нога, так это и называется "задача (или алгоритм ее решения) не масштабируется".

Тот же www.google.com, vk.com, youtube как-то работают ))) и "в скорость памяти" совершенно не упираются.

По поводу масштабируемый, RAC и прочего

Бог с ними с OLTP. Это нужно смотреть конкретный код. Возьмем замечательные и популярные ныне системы DWH. Oracle уже много лет назад, позволял делать Materialized View, Query Rewrite, что бы можно было данные __заранее__ пред-агрегировать и не выполнять всю агрегацию в момент обращения пользователя....

В каком же направление развивается ныне DWH решения?

Правильно - масштабирование, шардинг, партиционирование, RAC...

Возьмем 100500 ядер, выдадим им 100500 SSD дисков, разделим один SELECT SUM(*) c FULL TABLE SCAN по 100 Gb таблице на 100500 мелких Select'ов и будем выполнять их параллельно. Все ядра объединим по FC и InfiniBand. И все это назовем Oracle Exadata, а что бы пользователи понимали, что это не хухры мухры, их БД назовем BigDate и DWH....

А поскольку стоить это будет столько, что даже представить сложно... Exadata будем продавать не целиком, а половинками, четвертинами и по одной восьмой части )))

Только, лично у меня, почему-то возникают сомнения, что в 95% задач, которые решаются на таком оборудование, реально нужен FULL TABLE SCAN по 100-1000 GB таблицам ))). И нельзя было для реальных, практических запросов соорудить уже готовую агригацию на нужном уровне деталировки.

Как уже говорили в подфоруме работа про одну российскую компанию "при должно умение, старание и выделенном бюджете, любую базу данных можно сделать самой большой в Европе. И незачем этим гордиться" (не дословно, по памяти)

maytonПо поводу oracle - дайте время поискать пруфы. Это было во времена Oracle10g. Если найду - отпишу.
Да верю я, что было ограничение на число нод.
Ну и что с того? 64 ноды для Oracle это дофига и больше.

Будете готовы купить Oracle на 1024 ноды (думаю стоимость лицензии под миллиард долларов уйдет + саппорт под сотню миллионов в год), Ларри Эллисон лично для Вас персональную версию Oracle Database распорядится сделать и лично же вручит лицензию и DVD диск перевязанный ленточкой )))

Не думаю, что Ларри настолько богат, что бы терять клиента, готового заплатить миллиард долларов, из-за каких-то "проблем с сетью" )))

IMHO

maytonвсе примеры - разные и неудачные.

Примеры задач, которые успешно масштабируются

Бессмысленно говорить о производительности или масштабируемости "сферического коня". Одни задачи - лучше масштабируются, другие - хуже.

DWH - масштабируются более-менее хорошо, OLTP - хуже и может требовать __переписывание__ системы.

Аналогично и холивар JIT/не JIT. C / Java. Одни задачи решаются более эффективно/проще на одном средстве, другие на другом.

Ниши применения у них достаточно разные.

Никто в здравом уме не будет делать высокопроизводительные видео-кодеки на Java, просто потому, что Java не имеет нужных инструментов (например возможность писать код с SIMD инструкциями). Так же, вряд ли кто-то будет создавать сайт-визитку в I-net на Assembler'е и MMX/SSE командах, что бы "быстрее работало"

Но есть одно но... находясь в здравом уме. А знакомство с данным миром и даже данной конференцией ))), вполне убеждает, что данное сочетание слов ко многим людям применимо с большой натяжкой.

А вообще, нит рассуждений я уже потерял )))

Все началось с вброса, что кто-то "Мы очень долго пытались всех на%^&ть с JIT, но теперь признаем, что надо просто сделать обычный компилятор".

Желательно увидеть хоть какую-то ссылку на официальный сайт, где бы говорилось, что в следующей версии Java JIT не будет, а будет обычный компилятор.

Пока такого нет, обсуждать нечего. "Опять-таки случай так называемого вранья" ( C )

В 1.8 не знаю (они там с метаспейс больно уж намудрили), в предыдущих Java'ах JIT'у под скомпилированный код выдавали 32 Mb с возможным увеличением максимум до 64 Mb. Даже сильно enterprise проектам (Oracle Customer Care & Billing), вполне хватало