Используем правильные инструменты!
От: code8  
Дата: 16.09.11 11:36
Оценка: :)
Прошу высказываться по теме: "Пригодна ли JVM для реализации высоконагруженных (скажем, 1М TPS), low-latency (<10 ms) проектов" ?

Сразу скажу — я знаю про LMAX и иx Disruptor. Собственно, именно поэтому и хочу узнать ВАШЕ мнение — "а тот ли инструмент использовали эти ребята для борьбы False Sharing, Blocking и Races" ?

P.S. Очевидные "грабли" JVM для low latency hiload — проектов:
1. GC с его Stop the world
2. Отсутствие "прямого" способа борьбы с False sharing
3. Отсутствие "прямого" способа назначать thread affinity
4. Не эффективная реализация Atomic (CMPXCHG вместо XADD)
5. не управляемый JIT ...

Ребята в LMAX просто молодцы! Но нафига ???
Re: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 12:12
Оценка: +2
Здравствуйте, code8, Вы писали:

C>Прошу высказываться по теме: "Пригодна ли JVM для реализации высоконагруженных (скажем, 1М TPS), low-latency (<10 ms) проектов" ?

Многие проекты доказали что пригодна. А вот является ли оптимальным выбором, это ещё вопрос.

C>1. GC с его Stop the world

Это не основная проблема
Во-первых Stop the world устраняется правильными настройками.
Во-вторых GC сейчас всё более ориентирован на предсказуемые паузы.
Основная проблема это падение производительности на больших заполненых кучах.

C>Ребята в LMAX просто молодцы! Но нафига ???

Ну, как это всегда бывает. Мы знаем Java, мы на ней пишем.
Re[2]: Используем правильные инструменты!
От: Baudolino  
Дата: 16.09.11 12:14
Оценка: +1
C>>Ребята в LMAX просто молодцы! Но нафига ???
B>Ну, как это всегда бывает. Мы знаем Java, мы на ней пишем.
Осталось добавить, что в таком контексте выбор вполне может быть оптимальным. Всё ведь деньги решают, а не технологии.
Re[3]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 12:17
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Осталось добавить, что в таком контексте выбор вполне может быть оптимальным. Всё ведь деньги решают, а не технологии.

Вот именно Java может быть в экономическом плане более выгодной благодаря общей стабильности и другие enterprise вкусностям.
Re[3]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 12:35
Оценка:
Здравствуйте, Baudolino, Вы писали:

C>>>Ребята в LMAX просто молодцы! Но нафига ???

B>>Ну, как это всегда бывает. Мы знаем Java, мы на ней пишем.
B>Осталось добавить, что в таком контексте выбор вполне может быть оптимальным. Всё ведь деньги решают, а не технологии.
насчёт денег — золотые слова, не поспоришь... только это "риторический" ответ...
Re[4]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 12:47
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Baudolino, Вы писали:


B>>Осталось добавить, что в таком контексте выбор вполне может быть оптимальным. Всё ведь деньги решают, а не технологии.

B>Вот именно Java может быть в экономическом плане более выгодной благодаря общей стабильности и другие enterprise вкусностям.
Вот про "enterprise вкусности" — я всё больше прихожу к выводу, что это более маркетинг чем технологии. Какой enterprise-сервер выдерживает 1M TPS при латентности в пределах 10ms?

Вот и пишут они, страдальцы, "на коленке". Даже Collection им пришлось "перепилить" обратно в arrays. Не говоря уже об извращениям с "псевдоуправляемой" аллокацией объектов, которая работала в JDK 1.6, но перестала работать в JDK 1.7. А что будет есть "папа" этого решения (http://mechanical-sympathy.blogspot.com/) уйдёт из LMAX ?

Вообще, этот пример с LMAX таки заставляет задуматься о _НЕПРИЕМЛЕМОСТИ_ использования JAVA на hiload!

Для сферического enterprise в вакууме — да, для hiload — нет.

P.S. Уж простите, получилось излишне эмоционально...
Re[2]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 12:54
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, code8, Вы писали:


C>>Прошу высказываться по теме: "Пригодна ли JVM для реализации высоконагруженных (скажем, 1М TPS), low-latency (<10 ms) проектов" ?

B>Многие проекты доказали что пригодна. А вот является ли оптимальным выбором, это ещё вопрос.

C>>1. GC с его Stop the world

B>Это не основная проблема
B>Во-первых Stop the world устраняется правильными настройками.
настройки в студию пож-та
B>Во-вторых GC сейчас всё более ориентирован на предсказуемые паузы.
которые не совместимы с low latency ( < 10 ms ) на сколько-нибудь серьёзных кучах...
B>Основная проблема это падение производительности на больших заполненых кучах.
именно поэтому приходится постоянно думать о том где какой объект находится и сколько живёт... Вам не напоминает это С/C++ ?

И я снова спрашиваю, какая мне польза от GC, если я вынужден постоянно думать о том, как не дать ему повод почистить кучу ?

C>>Ребята в LMAX просто молодцы! Но нафига ???

B>Ну, как это всегда бывает. Мы знаем Java, мы на ней пишем.
Re[5]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 12:59
Оценка:
Здравствуйте, code8, Вы писали:

C>Вот про "enterprise вкусности" — я всё больше прихожу к выводу, что это более маркетинг чем технологии.

На маркетинг, а бизнес. Экономическая целесообразность, если хотите.

C>Какой enterprise-сервер выдерживает 1M TPS при латентности в пределах 10ms?

Как много вы знаете систем, которым нужен такой throughput?

C>Вот и пишут они, страдальцы, "на коленке". Даже Collection им пришлось "перепилить" обратно в arrays.

Коллекции кто только не переписывал уже. Скоро станет стандартной практикой.

C>Не говоря уже об извращениям с "псевдоуправляемой" аллокацией объектов, которая работала в JDK 1.6, но перестала работать в JDK 1.7.

BigMemory что ли? Презентацию ещё не досмотрел.
Это просто размен. Выбирая платформу ты получаешь её проблемы и решаешь их. Писали бы на С++ имели бы другие проблемы, изобратали бы другие решения.

C>Вообще, этот пример с LMAX таки заставляет задуматься о _НЕПРИЕМЛЕМОСТИ_ использования JAVA на hiload!

hiload это сложные проблемы на любой платформе. В чем заключается "неприемлимость"?

C>Для сферического enterprise в вакууме — да, для hiload — нет.

Че так оскорбительно-то? Enterprise делает деньги, а не hiload.
Re[2]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 13:01
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, code8, Вы писали:


C>>Прошу высказываться по теме: "Пригодна ли JVM для реализации высоконагруженных (скажем, 1М TPS), low-latency (<10 ms) проектов" ?

B>Многие проекты доказали что пригодна. А вот является ли оптимальным выбором, это ещё вопрос.

C>>1. GC с его Stop the world

B>Это не основная проблема
B>Во-первых Stop the world устраняется правильными настройками.
B>Во-вторых GC сейчас всё более ориентирован на предсказуемые паузы.
B>Основная проблема это падение производительности на больших заполненых кучах.

C>>Ребята в LMAX просто молодцы! Но нафига ???

B>Ну, как это всегда бывает. Мы знаем Java, мы на ней пишем.
Как-бы, да. Но не в данном случае. Почитайте блог автора Disruptor http://mechanical-sympathy.blogspot.com/
Его знания выходят далеко за рамки Java...
Re[3]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 13:08
Оценка:
Здравствуйте, code8, Вы писали:

B>>Во-первых Stop the world устраняется правильными настройками.

C>настройки в студию пож-та
Все перечислять что ли?
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
Тот же Ratio — если правильно сбалансировать поколения, то GC в tenured вообще будет делать особо нечего. Все объекты и в tenured и в eden будут собиратся в фоновых потоках, которые можно назначит на отдельные ядра, например.

B>>Во-вторых GC сейчас всё более ориентирован на предсказуемые паузы.

C>которые не совместимы с low latency ( < 10 ms ) на сколько-нибудь серьёзных кучах.
Ну, LMAX вроде бы доказывает что совместимы. Нет?

B>>Основная проблема это падение производительности на больших заполненых кучах.

C>именно поэтому приходится постоянно думать о том где какой объект находится и сколько живёт... Вам не напоминает это С/C++ ?
Постоянно думать, в отличие от C++, не приходится. На тестах всё прогоняется и конфигурируется единожды.

C>И я снова спрашиваю, какая мне польза от GC, если я вынужден постоянно думать о том, как не дать ему повод почистить кучу ?

Не постоянно, а только в периоды оптимизаций.
Re[3]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 13:09
Оценка:
Здравствуйте, code8, Вы писали:

C>Как-бы, да. Но не в данном случае. Почитайте блог автора Disruptor http://mechanical-sympathy.blogspot.com/

Спасибо. Почитаю.

C>Его знания выходят далеко за рамки Java...

Иначе бы у них ничего и не вышло.
Re[6]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 13:17
Оценка: -1
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, code8, Вы писали:


C>>Вот про "enterprise вкусности" — я всё больше прихожу к выводу, что это более маркетинг чем технологии.

B>На маркетинг, а бизнес. Экономическая целесообразность, если хотите.

C>>Какой enterprise-сервер выдерживает 1M TPS при латентности в пределах 10ms?

B>Как много вы знаете систем, которым нужен такой throughput?
Гы-гы... самое смешное, что такой throughput нужен для систем, которые обеспечивают движение основной массы денег — весь трейдинговый софт (операции на фондовом и валютном рынках), софт для MMOG, социальных сетей...

И да, Вы правы — в штуках таких систем не много... по сравнению с количеством инсталляций 1С
И что ? Вы сомневаетесь, что на разработке hiload можно заработать на феррари?

C>>Не говоря уже об извращениям с "псевдоуправляемой" аллокацией объектов, которая работала в JDK 1.6, но перестала работать в JDK 1.7.

B>BigMemory что ли? Презентацию ещё не досмотрел.
B>Это просто размен. Выбирая платформу ты получаешь её проблемы и решаешь их. Писали бы на С++ имели бы другие проблемы, изобратали бы другие решения.
Вы не поняли... перефразирую мысль... Попытка использовать Java в hiload приводит к необходимости придумывать "нестандартные" решения, которые:
1) перестают работать с выходом новой версии платформы
2) потенциально не поддерживаемы так как привязаны к голове автора

P.S. Предлагаю перевести дискуссию в более техническую сторону и показать, как в рамках JVM решить проблемы, обозначенные в моём исходном сообщении.
Re[7]: Используем правильные инструменты!
От: avpavlov  
Дата: 16.09.11 13:31
Оценка: +1
C>Гы-гы... самое смешное, что такой throughput нужен для систем, которые обеспечивают движение основной массы денег — весь трейдинговый софт (операции на фондовом и валютном рынках), софт для MMOG, социальных сетей...

про трейдинговый не скажу, а ММОГ и соц сети ты себе видать плохо представляешь.

ММОГ — много-много независимых серверов, соц-сети — просто балансировка на кластер.
Re[7]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 13:36
Оценка:
Здравствуйте, code8, Вы писали:

C>Гы-гы... самое смешное, что такой throughput нужен для систем, которые обеспечивают движение основной массы денег — весь трейдинговый софт

Ну так вроде кучу этого всего на Java и пишут. Не?
C>софт для MMOG,
Тут Java немного всралась как раз из-за проблем с большой кучей. Хотя есть и успешные проекты. Но рынок этот Java проморгала. В основном потому что ориентирована на RDBMS, транзакционность, web.
C>социальных сетей...
А с ними-то что не так? Их всё равно на чем писать, хоть на PHP, лишь бы руки из того места росли.

C>И да, Вы правы — в штуках таких систем не много... по сравнению с количеством инсталляций 1С

C>И что ? Вы сомневаетесь, что на разработке hiload можно заработать на феррари?
Что-то вы всё норовите во треп свести. На феррари можно и на казуалках заработать. Hiload проектов с такими показателями крайне мало. Для MMOG и социальных сетей Java чудесно масштабируется, так что выжимать миллисекунды не обязательно.

C>Вы не поняли... перефразирую мысль... Попытка использовать Java в hiload приводит к необходимости придумывать "нестандартные" решения, которые:

hiload это всегда компромис и нестандартые решения.

C>1) перестают работать с выходом новой версии платформы

Этого и без hiload хватает и для других платформ так же верно как и для Java.

C>2) потенциально не поддерживаемы так как привязаны к голове автора

Это вы какую-то фигню сморозили. При чем здесь голова автора?

C>P.S. Предлагаю перевести дискуссию в более техническую сторону и показать, как в рамках JVM решить проблемы, обозначенные в моём исходном сообщении.

ОК
Re[7]: Используем правильные инструменты!
От: hrensgory Россия  
Дата: 16.09.11 13:56
Оценка:
On 16.09.2011 17:17, code8 wrote:

> C>>Какой enterprise-сервер выдерживает 1M TPS при латентности в пределах

> 10ms?
> B>Как много вы знаете систем, которым нужен такой throughput?
> Гы-гы... самое смешное, что такой throughput нужен для систем, которые
> обеспечивают движение основной массы денег — весь трейдинговый софт
> (операции на фондовом и валютном рынках), софт для MMOG, социальных сетей...

Одиночному серверу такая скорострельность не нужна, а в соцсетях (и
много где ещё) всё вообще упирается в базы данных, но и те пишут иногда
на java (фейсбуковская cassandra). Про трейдинг не в курсе, возможно
там это действительно актуально.


> И да, Вы правы — в штуках таких систем не много... по сравнению с

> количеством инсталляций 1С
> И что ? Вы сомневаетесь, что на разработке hiload можно заработать на
> феррари?

Наёмному работнику не заработать никаких феррарей. А с точки зрения
бизнеса — найти заказчиков, которые оплатят вам феррари, значительно
проще занимаясь 1C/SAP/etc. чем hiload. Хотя они иногда причудливо
сплетаются.


> Вы не поняли... перефразирую мысль... Попытка использовать Java в hiload

> приводит к необходимости придумывать "нестандартные" решения, которые:

К таким последствиям приводит попытка обеспечить одним сервером "1M TPS
при латентности в пределах 10ms". Это просто действительно сложная
задача, независимо от выбора языка. В каждом подходе будут свои проблемы.


--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re[8]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 14:14
Оценка:
Здравствуйте, avpavlov, Вы писали:

C>>Гы-гы... самое смешное, что такой throughput нужен для систем, которые обеспечивают движение основной массы денег — весь трейдинговый софт (операции на фондовом и валютном рынках), софт для MMOG, социальных сетей...


A>про трейдинговый не скажу, а ММОГ и соц сети ты себе видать плохо представляешь.


A>ММОГ — много-много независимых серверов, соц-сети — просто балансировка на кластер.

всегда ?
Re[9]: Используем правильные инструменты!
От: avpavlov  
Дата: 16.09.11 14:18
Оценка:
A>>ММОГ — много-много независимых серверов, соц-сети — просто балансировка на кластер.
C>всегда ?

Во всяком случае про те что я читал — все (и ММОГ и сс) были организованы именно так. Нет смысла убиваться и делать один сервер, которого рано или поздно не хватит. Проще сразу думать в сторону балансировки.
Re[9]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 14:20
Оценка:
Здравствуйте, code8, Вы писали:

A>>ММОГ — много-много независимых серверов,

C>всегда ?
Почти да. Большинство MMOG это тупо ограниченые "комнаты" разбросаные по серверам. Остальные очень уникальные.

A>>соц-сети — просто балансировка на кластер.

Тут вообще без сомнений. Какие там нафиг нагрузки?
Re[10]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 14:23
Оценка:
Здравствуйте, avpavlov, Вы писали:

A>Во всяком случае про те что я читал — все (и ММОГ и сс) были организованы именно так. Нет смысла убиваться и делать один сервер, которого рано или поздно не хватит. Проще сразу думать в сторону балансировки.

+1. Вроде ни одной топовой MMOG, где можно собрать сотню тысяч игроков в одном месте нет. Есть уникальные решения где всё на одном сервере крутится. Но там всё равно внутренние сегментирование имеется.
Re[10]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 15:18
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, code8, Вы писали:


A>>>ММОГ — много-много независимых серверов,

C>>всегда ?
B>Почти да. Большинство MMOG это тупо ограниченые "комнаты" разбросаные по серверам. Остальные очень уникальные.

A>>>соц-сети — просто балансировка на кластер.

B>Тут вообще без сомнений. Какие там нафиг нагрузки?

ОК. Под "соц. сети" я имел ввиду сервисы, которые реализуют REST-API... да какая вообще разница ?
Есть задача, есть требования — "много коротких, быстрых сессий". Да, сейчас эта задача в основном решается в рамках реализации систем для финансовых рынков . И как показывает практика, решается успешно (по словам, LMAX, их Disruptor обрабатывает порядка 6M TPS за 1ms (в среднем)). И уже сейчас есть люди, с горящими глазами, желающие применять такую систему для MMOG-сервера (почему нет ?).

Disruptor _действительно_ красивое решение. Автор Disruptor назвал свой блог "Mechanical Sympathy". И в первой заметке он цитирует мысль "The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry". Задумайтесь над ней! Ведь правда же !?

Это напоминает мне тяни-толкая... "железячник" придумал кэш, "программер" придумал связанный список => энтропия сохранена
На бумаге связанный список выглядит круто и кому какое дело, то он не "кэш-френлди" ?

Или другой пример, было два ядра, стало 8. Раньше задача решалась за 1 сек, теперь за 2 сек (цифры условные). Что случилось ? False Sharing...
По-моему кризис налицо. Раньше мы покупали МГцы и были в шоколаде — нахер изучать работу процессора, нахер думать о том, как мой алгоритм будет исполняться на конкретном железе: "написал раз — работает везде"!!! Теперь мы покупаем ядра и думаем что всё будет как раньше... хрен. Ничего само не масштабируется. А новые ядра только усугубляют положение заставляя искать новые deadlocks и false sharing.

Это было лирическое отступление. Давайте вернёмся к задаче.
Как бы мы не убеждали себя, в её "специфичности" ситуация не изменится — задача (есть) и чем дальше тем чаще она будет возникать. А это значит, что нужно думать как её решать. Балансировка нагрузки это не решение задачи. Это способ не думать о решении задачи. Сейчас этот способ срабатывает, завтра — нет.

Я давно пишу на Java (а последние три года — только на Java).
И я хочу писать на Java hiload-проекты. Но степень "нестандартных" решений которые приходится принимать затачивая java-проект под hiload заставляет задуматься — а туда ли я иду ?

Очень прошу — отвечать по существу вопроса — какие _техники_ вы знаете для решения следующих проблем:
1. GC с его Stop the world
2. Отсутствие "прямого" способа борьбы с False sharing
3. Отсутствие "прямого" способа назначать thread affinity
4. Не эффективная реализация Atomic (CMPXCHG вместо XADD)
5. не управляемый JIT ...

Возможно у вас есть положительный опыт работы в связке C/C++ — JNI — JVM ?

Заранее благодарю!
Re[11]: Используем правильные инструменты!
От: hrensgory Россия  
Дата: 16.09.11 15:59
Оценка:
On 16.09.2011 19:18, code8 wrote:

> A>>>соц-сети — просто балансировка на кластер.

> B>Тут вообще без сомнений. Какие там нафиг нагрузки?
>
> ОК. Под "соц. сети" я имел ввиду сервисы, которые реализуют REST-API...
> да какая вообще разница ?
> Есть задача, есть требования — "много коротких, быстрых сессий".

Разница очень существенная. Эти самые "короткие быстрые REST-API сессии"
должны быть не только короткими и быстрыми, но и делать что-то
осмысленное. IRL, 99% всех приложений приходится для этого обращаться к
хранилищам данных, внешним по отношению к JVM (БД, ФС, etc.)

Как следствие, затык чаще всего получается на дисковом/сетевом IO а
совсем не при передаче данных между отдельными потоками в JVM, что на
первый взгляд и оптимизируют авторы Disruptor, хотя конечно вечер
пятницы не лучшее время для разбирательства в столь концептуальных вещах


> Это было лирическое отступление. Давайте вернёмся к задаче.

> Как бы мы не убеждали себя, в её "специфичности" ситуация не изменится —
> задача (есть) и чем дальше тем чаще она будет возникать. А это значит,
> что нужно думать как её решать. Балансировка нагрузки это не решение
> задачи. Это способ не думать о решении задачи. Сейчас этот способ
> срабатывает, завтра — нет.

"Я намерен жить вечно, пока всё идёт нормально" (с).

> Я давно пишу на Java (а последние три года — только на Java).

> И я хочу писать на Java hiload-проекты. Но степень "нестандартных"
> решений которые приходится принимать затачивая java-проект под hiload
> заставляет задуматься — а туда ли я иду ?

Расскажите в общих чертах какова ваша роль в этих предполагаемых "hiload
java-проектах", кто заказчик, какие задачи, какие альтернативы jvm
рассматривали и т.п. Очень интересная тема.


> Очень прошу — отвечать по существу вопроса — какие _техники_ вы знаете

> для решения следующих проблем:
> 1. GC с его Stop the world

В большинстве случаев лечится настройками.

> 2. Отсутствие "прямого" способа борьбы с False sharing

> 3. Отсутствие "прямого" способа назначать thread affinity
> 4. Не эффективная реализация Atomic (CMPXCHG вместо XADD)
> 5. не управляемый JIT ...

Ни разу не сталкивались с такими проблемами, возможно просто не умеем
такие ситуации диагностировать. Интересно было бы послушать как
диагностировать например false sharding. Вот у нас есть приложение,
работающее в jvm (AS) допустим в линуксе каком-нибудь — на что смотреть?

--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re[12]: Используем правильные инструменты!
От: Аноним  
Дата: 16.09.11 16:37
Оценка:
H>..., хотя конечно вечер пятницы не лучшее время для разбирательства в столь концептуальных вещах
H>
зато вечер пятницы — лучшее время для пятничного троллинга
Re[12]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 16:56
Оценка:
Здравствуйте, hrensgory, Вы писали:

H>On 16.09.2011 19:18, code8 wrote:


>> 2. Отсутствие "прямого" способа борьбы с False sharing

>> 3. Отсутствие "прямого" способа назначать thread affinity
>> 4. Не эффективная реализация Atomic (CMPXCHG вместо XADD)
>> 5. не управляемый JIT ...

H>Ни разу не сталкивались с такими проблемами, возможно просто не умеем

H>такие ситуации диагностировать. Интересно было бы послушать как
H>диагностировать например false sharding. Вот у нас есть приложение,
H>работающее в jvm (AS) допустим в линуксе каком-нибудь — на что смотреть?

Чудак-человек Я ж и говорю, что в Java нет "прямых" способов борьбы с false sharing.
Пока Вы не знаете про этот эффект — считайте Вам повезло.

Это как "эффект наблюдателя" в квантовой механике — пока его (наблюдателя) нет всё хорошо, как только он появляется — все меняется...

False sharing есть в ПО любого уровня. Просто большинству нет до него дела — гораздо важнее борьба с blocking IO и т.д...

Но в задачах, которые должны выжимать из железа максимум False sharing проявляется во всей красе... Этот эффект — следствие работы системы кэшировая CPU. Эта система обеспечивает когерентность локальных кэшей ядер. Чем больше ядер тем сильнее эффект от False sharing. Соответственно, начиная с 8-ми ядер игнорировать его нельзя уже для ПО любого уровня.

False sharing возникает когда несколько ядер читают или пишут данные, в пределах одной линии кэша (64 байта) — классический пример "массив счётчиков". Восемь потоков, каждый инкрементирует свой счётчик. Это работает в _десятки_ раз медленнее чем если бы каждый счётчик располагался в отдельной линии кэша (на расстоянии 64 байта друг от друга). Да — JIT может "оптимизировать" — разместить счётчик в регистре. Тогда False sharing не будет, но текущее значение счётчика не будет доступно из другого потока...

Чтобы убедиться, в наличии False sharing своего кода я рекомендую выполнить несколько вариантов тестирования в различной конфигурации processor affinity. И сравнить тайминги. Механизм, обеспечивающий когерентность кэшей будет проявлять себя по-разному и на тестах это видно.
Понимаю, что описал сумбурно — всё-таки, действительно, пятница-вечер, но, надеюсь, идею вы уловили
Re[11]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 16:57
Оценка:
Здравствуйте, code8, Вы писали:

C>1. GC с его Stop the world

— анализ и настройка
— вынос больших статичных данных из кучи — BigMemory или NoSQL.
— Real-time Java (экзотика, но всё же)

C>2. Отсутствие "прямого" способа борьбы с False sharing

Пока не разобрался на что оно влияет в hiload.

C>3. Отсутствие "прямого" способа назначать thread affinity

Оно зачем надо? Можно GC потоки назначить.

C>4. Не эффективная реализация Atomic (CMPXCHG вместо XADD)

Это и предыдущие два пункта лечатся через OpenJDK

C>5. не управляемый JIT

В каком смысле? Настроек много всяких. Чего не хватает?
Re[12]: Используем правильные инструменты!
От: code8  
Дата: 16.09.11 17:15
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, code8, Вы писали:


C>>1. GC с его Stop the world

B>- анализ и настройка
B>- вынос больших статичных данных из кучи — BigMemory или NoSQL.
B>- Real-time Java (экзотика, но всё же)

C>>2. Отсутствие "прямого" способа борьбы с False sharing

B>Пока не разобрался на что оно влияет в hiload.
почитайте моё предыдущее сообщение в этом треде...

C>>3. Отсутствие "прямого" способа назначать thread affinity

B>Оно зачем надо? Можно GC потоки назначить.
+ к производительности, если программный поток закрепляется за аппаратным (Disruptor V2 это доказал, вы знаете где почитать

C>>4. Не эффективная реализация Atomic (CMPXCHG вместо XADD)

B>Это и предыдущие два пункта лечатся через OpenJDK
а можно ссылку, что Atomic в OpenJDK реализован на XADD ?

C>>5. не управляемый JIT

B>В каком смысле? Настроек много всяких. Чего не хватает?
не хватает, например, memory alignment для борьбы с false sharing
Re[13]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 16.09.11 17:30
Оценка: :)
Здравствуйте, code8, Вы писали:

C>а можно ссылку, что Atomic в OpenJDK реализован на XADD ?

Какую ещё ссылку? Качаем и правим.
Re: Используем правильные инструменты!
От: sergmesh  
Дата: 17.09.11 18:34
Оценка:
Здравствуйте, code8, Вы писали:

C>Прошу высказываться по теме: "Пригодна ли JVM для реализации высоконагруженных (скажем, 1М TPS), low-latency (<10 ms) проектов" ?


C>Сразу скажу — я знаю про LMAX и иx Disruptor. Собственно, именно поэтому и хочу узнать ВАШЕ мнение — "а тот ли инструмент использовали эти ребята для борьбы False Sharing, Blocking и Races" ?


C>P.S. Очевидные "грабли" JVM для low latency hiload — проектов:

C>1. GC с его Stop the world
C>2. Отсутствие "прямого" способа борьбы с False sharing
C>3. Отсутствие "прямого" способа назначать thread affinity
C>4. Не эффективная реализация Atomic (CMPXCHG вместо XADD)
C>5. не управляемый JIT ...

в сторону erlang смотрели?
Re[11]: Используем правильные инструменты!
От: avpavlov  
Дата: 18.09.11 07:45
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, avpavlov, Вы писали:


A>>Во всяком случае про те что я читал — все (и ММОГ и сс) были организованы именно так. Нет смысла убиваться и делать один сервер, которого рано или поздно не хватит. Проще сразу думать в сторону балансировки.

B>+1. Вроде ни одной топовой MMOG, где можно собрать сотню тысяч игроков в одном месте нет. Есть уникальные решения где всё на одном сервере крутится. Но там всё равно внутренние сегментирование имеется.

есть EVE online, где мир для всех игроков единый, но там есть "естественная" точка сегментирования нагрузки на сервера — звездные системы и планеты.
Re[2]: Используем правильные инструменты!
От: Аноним  
Дата: 19.09.11 06:07
Оценка:
S>в сторону erlang смотрели?
пятница закончилась, тролль уже затих.
не кормите троллей, не будите их.
Re[13]: Используем правильные инструменты!
От: Nicht Россия  
Дата: 19.09.11 07:20
Оценка:
Здравствуйте, code8, Вы писали:


C>False sharing возникает когда несколько ядер читают или пишут данные, в пределах одной линии кэша (64 байта) — классический пример "массив счётчиков". Восемь потоков, каждый инкрементирует свой счётчик. Это работает в _десятки_ раз медленнее чем если бы каждый счётчик располагался в отдельной линии кэша (на расстоянии 64 байта друг от друга). Да — JIT может "оптимизировать" — разместить счётчик в регистре. Тогда False sharing не будет, но текущее значение счётчика не будет доступно из другого потока...


Вообще довольно интересное утверждение на счет массива.
Вот есть такая штука от Cliff Click ConcurrentAutoTable. По сути дела это атомарный счетчик, который распределяет CAS операции на массив, вместо того, чтобы обновлять один регистр. И автор утверждает следующие:

Updates are striped across an array of counters to avoid cache contention
and has been tested with performance scaling linearly up to 768 CPUs.


Что как бе говорит нам что не так все плохо.

Вообще складывается впечатление, что ты рекламируешь этот disruptor. Ты его разрабатываешь что ли? Хотя, судя по коду, там вообще кроме этого paddedlong и нет ничего. Но и там реализация довольно спорная. Наклепал филдов в класс что бы кеш линию забить и все. Тестов нет, вообще говоря. Что произойдет, если на платформе будет другой размер кеш линии? Да и выделение на регистр целой линии кеша, довольно спорное. Их, этих линий, нифига не бесконечно колличество. Где процессор будет хранить другие переменные приложения, когда все кеш линии будут заняты этими мегалонгами?
Микробенчмарки в блоге, не сильно хорошо сделаны. Но вроде действительно работет быстрее. Технику можно взять на вооружение, но носиться с ней как с писаной торбой, думаю, смысла нет.
Re[12]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 19.09.11 07:48
Оценка:
Здравствуйте, avpavlov, Вы писали:

A>есть EVE online, где мир для всех игроков единый, но там есть "естественная" точка сегментирования нагрузки на сервера — звездные системы и планеты.

Такие "естественные" точки сегментирования везде и делают. В EVE тоже вроде ограничение до 200 кораблей в битве (т.е. сегменте)? Там вместо кластера всё по блейдам разбросано. Суть та же самая, хотя хардварно железка как бы одна.
Re[13]: Используем правильные инструменты!
От: Blazkowicz Россия  
Дата: 19.09.11 11:22
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Такие "естественные" точки сегментирования везде и делают. В EVE тоже вроде ограничение до 200 кораблей в битве (т.е. сегменте)? Там вместо кластера всё по блейдам разбросано. Суть та же самая, хотя хардварно железка как бы одна.

Соврал. Ограничения, действительно, нет. Но при определенном количестве клиентов начинаются лаги, по причине всё той же сегментированой структуры.
Re: Используем правильные инструменты!
От: StanislavK Великобритания  
Дата: 19.09.11 12:55
Оценка:
Здравствуйте, code8, Вы писали:

C>Прошу высказываться по теме: "Пригодна ли JVM для реализации высоконагруженных (скажем, 1М TPS), low-latency (<10 ms) проектов" ?

Пригодна. Трейдинговые системы на ней радостно бегают и реально быстро.

C>Сразу скажу — я знаю про LMAX и иx Disruptor. Собственно, именно поэтому и хочу узнать ВАШЕ мнение — "а тот ли инструмент использовали эти ребята для борьбы False Sharing, Blocking и Races" ?

C>Ребята в LMAX просто молодцы! Но нафига ???
Ну рабоает же
Думаю, что какой бы тул (более-менее адекватный, ессесно) не был выбран, все равно будут проблемы и их сложность будет примерно одинаковая. На яве одно, на плюсах или где-то еще — другое.
Не касаемо перфоменса, на яве удобно, что клиент может пользовать те же библиотеки протокола, что и сервер. Это бенефит, если клиент тоже на яве.
Re[3]: Используем правильные инструменты!
От: code8  
Дата: 19.09.11 17:57
Оценка:
Здравствуйте, Аноним, Вы писали:

S>>в сторону erlang смотрели?

А>пятница закончилась, тролль уже затих.
А>не кормите троллей, не будите их.
зло...
Re[14]: Используем правильные инструменты!
От: code8  
Дата: 19.09.11 18:10
Оценка:
Здравствуйте, Nicht, Вы писали:

N>Здравствуйте, code8, Вы писали:



C>>False sharing возникает когда несколько ядер читают или пишут данные, в пределах одной линии кэша (64 байта) — классический пример "массив счётчиков". Восемь потоков, каждый инкрементирует свой счётчик. Это работает в _десятки_ раз медленнее чем если бы каждый счётчик располагался в отдельной линии кэша (на расстоянии 64 байта друг от друга). Да — JIT может "оптимизировать" — разместить счётчик в регистре. Тогда False sharing не будет, но текущее значение счётчика не будет доступно из другого потока...


N>Вообще довольно интересное утверждение на счет массива.

N>Вот есть такая штука от Cliff Click ConcurrentAutoTable. По сути дела это атомарный счетчик, который распределяет CAS операции на массив, вместо того, чтобы обновлять один регистр. И автор утверждает следующие:
N>

N>Updates are striped across an array of counters to avoid cache contention
N>and has been tested with performance scaling linearly up to 768 CPUs.


N>Что как бе говорит нам что не так все плохо.

насчёт записи в массив, ячейки которого размещаются в одной кэш-линии, из разных _ядер_ поясню:
— каждое ядро имеет свой кэш
— операция записи требует чтобы кэш ядра стал "хозяином" кэш-линии, в которую производится запись
— "хозяин" у кэш-линии всегда один
— если несколько ядер пишут в одну и туже кэш-линию происходит постоянная "смена хозяина"
— "смена хозяина" предполагает получение подтверждений от всех ядер (чем больше ядер-тем дольше)

фактически, это описание MESI-протокола.
но вы можете не верить — и так работает, какая разница как...
Re[15]: Используем правильные инструменты!
От: Nicht Россия  
Дата: 20.09.11 07:05
Оценка:
Здравствуйте, code8, Вы писали:

C>фактически, это описание MESI-протокола.

C>но вы можете не верить — и так работает, какая разница как...

Что значит не верю? Я понимаю что все так и происходит, как ты говоришь. Просто мне кажется тикаие вещи надо отдавать на откуп оптимизирующему компилятору, а не писать давольно спорные костыли.
Я говорил про то, что забивать кешлинии — значит мешать оптимизирующему компилятору и процессору делать их работу. Тоесть за место того что бы гонять почти пустые кешлинии по систем басу, процессор мог бы что нибудь еще засинхронизировать, а так он по сути синхронизирует только один регистр. Опять же смущает платформозависимая реализация. И крайне смущают некомпетентные микробенчмарки в блоге.
Re[16]: Используем правильные инструменты!
От: code8  
Дата: 20.09.11 18:10
Оценка:
Здравствуйте, Nicht, Вы писали:

N>Что значит не верю? Я понимаю что все так и происходит, как ты говоришь. Просто мне кажется тикаие вещи надо отдавать на откуп оптимизирующему компилятору, а не писать давольно спорные костыли.

N>Я говорил про то, что забивать кешлинии — значит мешать оптимизирующему компилятору и процессору делать их работу. Тоесть за место того что бы гонять почти пустые кешлинии по систем басу, процессор мог бы что нибудь еще засинхронизировать, а так он по сути синхронизирует только один регистр. Опять же смущает платформозависимая реализация. И крайне смущают некомпетентные микробенчмарки в блоге.
круто было бы если бы "оптимизирующий" компилятор сам разруливал ситуации, когда возникает этот false sharing... только вот как это ему сделать если этот эффект проявляет себя только на runtime ?
так что хочешь-не хочешь, а когда нужно выжать 100% придется лезть руками...и кроме как гонять "пустые" кэш-линии я способа не знаю... а Вы ?

мне кажется, когда речь заходит о concurrency и scalability нужно думать в терминах "железа". а железу пофиг на биты-байты, оно кэш-линиями оперирует.
Re[17]: Используем правильные инструменты!
От: Nicht Россия  
Дата: 21.09.11 06:31
Оценка:
Здравствуйте, code8, Вы писали:

C>круто было бы если бы "оптимизирующий" компилятор сам разруливал ситуации, когда возникает этот false sharing... только вот как это ему сделать если этот эффект проявляет себя только на runtime ?

C>так что хочешь-не хочешь, а когда нужно выжать 100% придется лезть руками...и кроме как гонять "пустые" кэш-линии я способа не знаю... а Вы ?

Ты не поверишь. В java оптимизирующий компилятор работает именно в рантайме. И как раз из за этого меня смущают плохие микробенчмарки. Они просто не дают компилятору наормально развернуться. Но, по правде сказать, я с ходу не нагуглил того что в hotspot opto есть какие — то false sharing оптимизации. Но я тут не вполне компетентен.
Re[4]: Используем правильные инструменты!
От: abch-98-ru Россия  
Дата: 21.09.11 08:38
Оценка:
что не тролль, что ли? звиняй тогда
в качестве извинения — копай откуда-нибудь отсюда. там про atomic_add на xadd (сюрприз ) под linux_x86. аналог под своё найдёшь, если надо.
а с остальными своими непонятками ты уж как-нить сам )
Re[5]: Используем правильные инструменты!
От: code8  
Дата: 21.09.11 19:41
Оценка:
Здравствуйте, abch-98-ru, Вы писали:

A9R>что не тролль, что ли? звиняй тогда

A9R>в качестве извинения — копай откуда-нибудь отсюда. там про atomic_add на xadd (сюрприз ) под linux_x86. аналог под своё найдёшь, если надо.
о, клёва! благодарю!
Re[18]: Используем правильные инструменты!
От: code8  
Дата: 21.09.11 20:04
Оценка:
Здравствуйте, Nicht, Вы писали:

N>Здравствуйте, code8, Вы писали:


C>>круто было бы если бы "оптимизирующий" компилятор сам разруливал ситуации, когда возникает этот false sharing... только вот как это ему сделать если этот эффект проявляет себя только на runtime ?

C>>так что хочешь-не хочешь, а когда нужно выжать 100% придется лезть руками...и кроме как гонять "пустые" кэш-линии я способа не знаю... а Вы ?

N>Ты не поверишь. В java оптимизирующий компилятор работает именно в рантайме. И как раз из за этого меня смущают плохие микробенчмарки. Они просто не дают компилятору наормально развернуться. Но, по правде сказать, я с ходу не нагуглил того что в hotspot opto есть какие — то false sharing оптимизации. Но я тут не вполне компетентен.

ок — я под "компилятор" принял javac... да, JIT, теоретически, мог был разруливать. Тока я сходу не могу придумать как его научить отделять мух от котлет без потери перформанса — а иначе какой в этом смысл...

поясни пож-та, в чём твои сомнения — что значит "плохие микробенчмарки" ?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.