Последним реально эффективным ускорением тяжелого приложения на java был переезд на две новые железки (каждая 2 xeon E5630, 24G RAM, зеркальные рейды), один — app, второй — sql. Два месяца работы сравнимы со стоимостью железки, память «оптимизируется» только в случае существенных утечек, дешевле купить ещё пару планок памяти.
Интерес оптимизации часто остаётся именно спортивным. 100к руб профессионального программиста java в месяц — 10 плашек по 16Gb (Kingston KVR1066D3Q4R7S/16G). Аналогичная ситуация по другим узким местам.
Хотя, конечно, я смотрю на это с точки зрения системного администрирования и опыта менеджмента нагруженных проектов.
tar закапывает проблему при появлении существенных объёмов.
в остальном, конечно, велосипеды это всё. Либо игры при изучении линухов, либо спец задача (например, многоточечный бекап медиахранилища по узким каналам у меня).
Здравый подход, вот только в работе стараюсь держаться подальше от настроений:
«Эта схема, согласованная с заказчиком, позволила легко отсечь ряд хотелок.»
цель исполнителя — не дать поворот от ворот. опыт позволяет предвидеть большинство хотелок и некоторые из желаний клиента весьма здравые. хорошо иметь опыт работы как с той, так и с другой стороны.
Я считаю, что отказоустойчивость продакшна обеспечиваться серверной «прочностью» и избыточностью.
Примеры в стиле «тестовый сервер» стоят на чем попало, а ставить критичные сервисы на несерверное железо мы зареклись.
«только параллелограмм в стойке?»
Можно прикопаться к тому, что далеко не все сервера rack-mount и привести примеры. Мысль, я думаю, была не в этом. Речь именно о десктопном и серверном железе, можно десктопную мать со всем фаршем засунуть в 4u и оставить работать.
смотрится как оплеуха «главный пункт программы Bitcoin… не выдерживает критики.» бездоказательно. Криптосистемы я привык видеть как строгие математические выкладки и обоснования с точки зрения логики.
Везде, где люди дали рубль в систему, её уже пытались взламывать и анализировать.
сейчас ещё сохраняется проблема с добавлением дисков в 6 рейды в центосе из-за 2.6.18 и «нового» функционала с ядра 2.6.21. И обход этой проблемы известен, да и 6 центос близок.
правильный набор команд просто элементарно гуглится.
он говорил не о своём железе, а о загрузке процессора на обработку.
включил фичу — загрузка упала, гигабит отдается полностью. померили загрузку и прикинули, сколько бы мы смогли отдавать… чтобы загрузить это место по полной.
не факт, что это действительно насущное для автора поста.
может быть для них это было эмпирическим фактом.
провели набор тестов большой на конкретной версии и выяснили — n+1 даёт лучший результат. так и используют следующие несколько версий, принимая на веру старый результат.
выглядит странно, но иногда выключают HT при вычислениях.
мануалы хендбука с генту.орг есть на русском языке. там пространно и аргументированно расписано.
приходилось восстанавливать систему, переставляя материнку и проц на более старые. переоптимизированная система при этом, очевидно, работать не хотела.
не оптимизируйте под процессор, если не уверены.
людей, которым нужно оттачивание под конкретные фичи процессора встречались только на кластере, где было массовое пережатие видео и все радовались как дети выигрышу в единицы процентов.
за статью спасибо, однако не понятно, почему на 150 мегабитах в секунду встает эта проблема.
на моей практике:
раздача крупной статики на 400-600 мегабит/секунду ограничивалась дисковой подсистемой.
router\firewall на достаточно слабой (~гигагерц) однопроцессовой машине не загружен при 100 мегабитном потоке в одну сторону и 70 мегабитном в другую. 2 карточки (на самом деле их 3, не меняет сути дела).
Могу логи выдать в момент нагрузки, если интересно.
Вопрос, видимо к постановке проблемы, входящим условиям. Не к описанному методу решения.
Интерес оптимизации часто остаётся именно спортивным. 100к руб профессионального программиста java в месяц — 10 плашек по 16Gb (Kingston KVR1066D3Q4R7S/16G). Аналогичная ситуация по другим узким местам.
Хотя, конечно, я смотрю на это с точки зрения системного администрирования и опыта менеджмента нагруженных проектов.
tar закапывает проблему при появлении существенных объёмов.
в остальном, конечно, велосипеды это всё. Либо игры при изучении линухов, либо спец задача (например, многоточечный бекап медиахранилища по узким каналам у меня).
«устранён провал по скорость в час пик»
устранён провал по скоростИ в час пик
«Эта схема, согласованная с заказчиком, позволила легко отсечь ряд хотелок.»
цель исполнителя — не дать поворот от ворот. опыт позволяет предвидеть большинство хотелок и некоторые из желаний клиента весьма здравые. хорошо иметь опыт работы как с той, так и с другой стороны.
и если уж сильно прикапываться, то ethernet — тоже избыточное требование, хотя это наиболее распространенное решение.
исправьте опечатку с ФАЛами
Примеры в стиле «тестовый сервер» стоят на чем попало, а ставить критичные сервисы на несерверное железо мы зареклись.
«только параллелограмм в стойке?»
Можно прикопаться к тому, что далеко не все сервера rack-mount и привести примеры. Мысль, я думаю, была не в этом. Речь именно о десктопном и серверном железе, можно десктопную мать со всем фаршем засунуть в 4u и оставить работать.
по принципу наличности можно сделать перевод яндекс-деньгами. и вообще есть платежные системы, основанные именно на таком принципе.
биткойн изначально на этом основан и не обеспечен чем-то материалным при этом.
смотрится как оплеуха «главный пункт программы Bitcoin… не выдерживает критики.» бездоказательно. Криптосистемы я привык видеть как строгие математические выкладки и обоснования с точки зрения логики.
Везде, где люди дали рубль в систему, её уже пытались взламывать и анализировать.
за что они выделили центос и не выделили рхел — вот этот вопрос интереснее.
сейчас ещё сохраняется проблема с добавлением дисков в 6 рейды в центосе из-за 2.6.18 и «нового» функционала с ядра 2.6.21. И обход этой проблемы известен, да и 6 центос близок.
правильный набор команд просто элементарно гуглится.
включил фичу — загрузка упала, гигабит отдается полностью. померили загрузку и прикинули, сколько бы мы смогли отдавать… чтобы загрузить это место по полной.
не факт, что это действительно насущное для автора поста.
провели набор тестов большой на конкретной версии и выяснили — n+1 даёт лучший результат. так и используют следующие несколько версий, принимая на веру старый результат.
выглядит странно, но иногда выключают HT при вычислениях.
мануалы хендбука с генту.орг есть на русском языке. там пространно и аргументированно расписано.
приходилось восстанавливать систему, переставляя материнку и проц на более старые. переоптимизированная система при этом, очевидно, работать не хотела.
не оптимизируйте под процессор, если не уверены.
людей, которым нужно оттачивание под конкретные фичи процессора встречались только на кластере, где было массовое пережатие видео и все радовались как дети выигрышу в единицы процентов.
на моей практике:
раздача крупной статики на 400-600 мегабит/секунду ограничивалась дисковой подсистемой.
router\firewall на достаточно слабой (~гигагерц) однопроцессовой машине не загружен при 100 мегабитном потоке в одну сторону и 70 мегабитном в другую. 2 карточки (на самом деле их 3, не меняет сути дела).
Могу логи выдать в момент нагрузки, если интересно.
Вопрос, видимо к постановке проблемы, входящим условиям. Не к описанному методу решения.