Плохо работающее JAVA-приложение по сравнению с плохо работающим сервером

Sherlock!

Как только вы устраните невозможное, что бы ни осталось, как бы невероятно, должно быть правдой. -Артур Конан Дойл

Сначала вы можете посмотреть этот разговор, в котором обсуждаются источники проблем с производительностью и способы их диагностики. Он сравнивает Linux со SmartOS, которая является своего рода отдельным от точки зрения вашей должности, но это также помогает выяснить, откуда проблемы с производительностью.

Обычно, когда вы отлаживаете проблемы с производительностью программного обеспечения, вы должны попытаться воспроизвести точно такую же конфигурацию программного обеспечения на отдельной физической машине, с той же версией Java, то же ядро, то же пользовательское пространство и т.д.. Если проблемы с производительностью не существуют, то вы можете начать рассматривать проблемы физического оборудования, гипервизора/контейнера, или проблемы установки на вашем компьютере.

Если пользователь никогда раньше не запускал это программное обеспечение в данной конкретной конфигурации ОС/версии, то он не может сразу же заявить, что это ваш сервер. Я бы лучше возложил бремя доказывания на их , чтобы продемонстрировать, что при работе CentOS 6 (с той же самой младшей версией и тем же гипервизором и той же самой операционной системой хоста, если она не запущена на пустом металле), они могут получить лучшую производительность.

Если же лучшая производительность в этом случае достигается за счет того, что они имеют гораздо лучшие системные характеристики (например, они запустили ее на 1 ГБ KVM на низкопроизводительном процессоре вашей инфраструктуры, но на собственной 24-ядерной системе Ivy Bridge E5 с 8 твердотельными накопителями PCIe в аппаратном RAID0, то это на 1000% быстрее), то можно начинать говорить о физическом аппаратном обеспечении. Если физическое аппаратное обеспечение такое же или очень похожее, то можно начать говорить о конфигурации ОС/гипервизора.

Можно также рассмотреть возможность того, что, исходя из производительности приложения и количества пользователей и нагрузки на данные, аппаратное обеспечение, выделенное пользователю, просто недостаточно для выполнения задачи. Если это очень важный клиент и поддержание его счастливого состояния критически важно для вашего бизнеса, вы можете попробовать отступить от некоторых ограничений, которые вы можете наложить на его виртуальный контейнер или экземпляр ВМ; например, временно дать им больше оперативной памяти или процессорного времени, пропускной способности сети и т.д., и посмотреть, поможет ли это. Если это поможет, вам, возможно, придется сказать пользователю, что ему придется заплатить за большую ВМ, чтобы получить желаемую производительность на этой рабочей нагрузке.

Escaping The Burn (когда это не ваша проблема)

Если по каким-то причинам пользователь отказывается попробовать ту же самую конфигурацию программного обеспечения на отдельном оборудовании, вам придется прибегнуть либо помочь им устранить проблему с производительностью в их приложении (что может быть трудно невозможным на Linux, как Брендан Грегг описывает в своем выступлении; иногда вы можете просто "носить", что стоимость производительности), или просто настаивать на том, что пользователь неправильно. Это прискорбный побочный эффект поддержки разработчиков на ваших системах.

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

Если вы предоставляете неуправляемый хостинг или иным образом согласились помочь людям, работающим с программным обеспечением, в их неприятностях, независимо от того, является ли проблема их виной, Вам, возможно, придется засучить рукава, запачкать руки и запустить более сложные инструменты профилирования производительности, чтобы увидеть, можете ли вы заметить фактическую проблему. Неужели это просто блокировка чатового протокола на сетевом сокет-соединении? Ограничен ли он входом/выходом из памяти? Или в BIOS не включен VT-x? Есть слишком много возможностей, чтобы даже перечислить.

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

Fanning the Flames (когда это Ваша проблема)

Поскольку общей темой "кажется" Java, Вы могли бы начать, по крайней мере, с определения того, работает ли сам Java-процесс на каком-то крайне медленном коде. Для этого, в идеале, разработчик/пользователь/клиент сможет предоставить вам исходный код своей Java программы (и всех зависимых библиотек).

Попробуйте запустить программу под хорошим профилировщиком . Существуют свободные и несвободные профайлеры; примером свободного является тот, который поставляется с NetBeans. Успешный запуск профайлера и инструментария вашего приложения может быть непростой задачей, в зависимости от того, что именно представляет собой это приложение, но результаты почти всегда говорят в некотором роде.

Конечно, вы можете прибегнуть к использованию htop и/или iotop, чтобы определить, делает ли ВМ Java (или связанная с ней СУБД) непомерное количество процессоров, ввода/вывода памяти или дисковых вводов/выводов, превышающее "разумный" объем, который вы считаете "разумным" (учитывая аппаратное обеспечение и рабочую нагрузку). Это чрезвычайно широкие инструменты, и не всегда дают полную картину, потому что иногда проблемы с производительностью связаны с тем, что программа не делает, пока она ждет чего-то другого, что может быть не связано с "узким местом" в ресурсах. Это примерно как общий шаг по устранению неполадок, как попытка запустить машину, чтобы определить, правильно ли работает двигатель или нет. Если он не запускается, что же делать? Вот почему правильный профилировщик Java может пригодиться, если вам действительно нужно глубокое погружение.

Наконец, я просто повторю то, что сказал Брендан Грегг в своей речи, и упомяну DTrace. Полная функциональность DTrace еще не реплицировалась на Linux, ни реимплементацией dtrace-on-linux, ни какими-либо конкурентами, например SystemTap. Тем не менее, вы можете попробовать использовать один из этих инструментов, и посмотреть, поможет ли это. Некоторые понимания могут быть лучше, чем ни одного .

Вам, конечно, понадобятся специальные знания и опыт использования этих самых "швейцарских ножей" типа "швейцарский нож". Большую часть этих знаний вы получите благодаря большому опыту (читайте: пробные версии, ошибки и гуглинг). Речь не идет о том, чтобы просто запустить инструмент и позволить ему указать вам на проблему; вам нужно будет вывести проблему из строя на основе имеющихся данных. Это не просто. Производительность редко бывает такой.