Настройка и отслабване JBossAS

въз основа на JBoss 3.2.6

jbossastuningslimming

РЕВИЗИРАН ЗА 4.0.4+ JBoss4Slimming

Предговор

Този съвет е предимно за това как да настроите и/или тънък JBossAS. Двете концепции са ортогонални в повечето случаи. Въпреки че намаляването на празните нишки на услуги чрез отслабване няма да има голямо влияние върху производителността, използването на по-малко памет и ресурси може да ви позволи да настроите други аспекти на производителността. Разбира се, това намалява времето за стартиране. Освен това, като обща концепция за сигурност - премахнете услугите, които не използвате. Ще отделим двете категории: отслабване и настройка. Започваме с използване на конфигурацията по подразбиране и изрязването от там (за клъстериране, което ще бъде темата на по-късна wiki страница). Този съвет не включва области на настройка, които са напречни програмист и администраторски роли (настройка на приложения, като например размера на кеша). Това е преди всичко съвет за административна настройка.

Забележете за заинтересованите, че този съвет ще направи технически несъответстващ на J2EE екземпляр на JBoss (3.2.6 така или иначе не е съвместим), тъй като премахването на ключови J2EE услуги би довело до това JBoss да провали TCK. Повечето задачи за настройка на производителността/административни задачи, изпълнявани в реални инсталации, технически попадат в тази категория.

Да предположим, че сте копирали директорията сървър/по подразбиране и нейните поддиректории в server/slim.

Настройка

Виртуална машина Java

Използвайте 64-битова машина и 64-битова VM, за да можете да използвате големи размери на купчина, обикновено по-големи от 2-4 GB. 64-битова поддръжка е достъпна за всички скорошни кутии SPARC/Solaris, работещи със Solaris 9 или по-нова версия, Itanium с JDK 1.4 или JDK 5 на Linux x64.

НЕ ИЗПОЛЗВАЙТЕ -d64 (64-битова), ако не използвате НАД НАД 32-битовото пространство за купчина (2-4 GB купчина). Използването на 64-битово адресиране изисква ПОВЕЧЕ памет за извършване на същото количество работа и не предоставя предимство за приложения, които не се нуждаят от толкова много памет.

Избягвайте много големи купчини, но избягвайте много малки купчини. (Не можем да ви кажем какво отговаря на изискванията, защото зависи от това, което правите). Това се отразява на събирането на боклук от поколения и общото време за сканиране на купчината. Трудно е да настроите ефективно малко купчина (дори ако приложението ви използва само 200 MB, ако използвате паралелно събиране на боклук + CMS, тогава ще ви трябват доста над 512 MB). Големите купчини прекарват ненужно време в сканиране на паметта за събиране на боклука.

Избягвайте Слънцето 1.4 VM. JDK 5 е НАСТЪПНО по-добър, особено в областта на събирането на боклука.

Използвайте опцията -server, но използвайте или -XX: ThreadStackSize = 128k (Solaris) или -Xss128k (всяка друга платформа). На Solaris -Xss128k не прави нищо (можете да зададете само по-големи размери на стека нишки). Това ви позволява да създавате повече нишки, като използвате по-малко памет за нишка, но може да доведе до издухани стекове с изключително рекурсивен код. И все пак, 128k стек все още не е нещо, което да се разклати.

Наистина трябва да разберете генераторите за събиране на боклук, за да настроите това правилно и наистина трябва да направите тестване на натоварването (OpenSTA, JMeter и т.н.), за да знаете със сигурност.

Наистина трябва да използвате многопроцесорна машина с повече от 2 процесора и да използвате различни паралелни и едновременни опции за събиране на боклука (ние обхващаме това в подсказката за разширено обучение на JBoss Training) за максимална производителност и висока производителност на събирача на боклука. Наистина обаче трябва да разберете как работи събирането на боклука, за да настроите това добре. JDK 5 е предимно самонастройка.

По подразбиране NewSize на JDK 1.4 не е добро предположение. Лошо правило: JBoss/Java на Linux

Ако използвате JBoss AS на Linux сървър, трябва да прочетете тази статия, написана от Andrew Oliver, един от JBoss, подразделение на Red Hat, консултанти за това как да настроите JBoss/Java в Linux сървър

Tomcat

Редактирайте вашия сървър/slim/jbossweb-tomcat5? .Sar/server.xml

Проверете XML документа за съединители, които използвате. Например, HTTP съединителят:

Трябва да имате достатъчно нишки (maxThreads), за да обработвате (правило на палеца) с 25% повече от максималното ви очаквано натоварване (едновременни посещения, идващи наведнъж)

Трябва да имате minSpareThreads, равни само малко повече от нормалното ви натоварване

Трябва да имате maxSpareThreads, равни само малко повече от вашето пиково натоварване

означава "при стартиране, винаги дръжте поне толкова много нишки в чакане"

означава "ако някога отидем над minSpareThreads, тогава винаги оставяйте maxSpareThreads да чака в неактивно състояние"

Премахнете всички ненужни клапани и регистрация. Ако не използвате защитата на JBoss, премахнете предпазния клапан (вижте по-долу).

Предкомпилирайте JSP. (Вграденият компилатор е доста бърз, може да не си струва за малки сайтове.)

Изключете режима на "развитие" във вас sever/slim/jbossweb-tomcat50.sar/conf/web.xml

За JBoss 4.0.5:

За деактивиране на режима за разработка в Tomcat:

Редактирайте $ JBOSS_HOME/server/slim/deploy/jbossweb-tomcat55.sar/conf/web.xml и потърсете jsp

Добавяне:

RMI за отдалечени призовавания

По подразбиране JBoss създава нова нишка за всяка RMI заявка, която постъпва. Това обикновено не е ефективно за голяма система. На второ място, може да бъде опасно да се разрешат неограничени връзки в случай на повишаване на производителността или трафик или създаване на клиентски връзки. За да коригирате това, трябва да помислите за преминаване към обединен повикващ.

Променете всички обвързващи прокси сървъри към обединения извиквател, като промените всеки XML фрагмент четене:

JBoss също има предимно недокументиран PooledInvokerHA, който можете да опитате.

Log4j

Регистрацията има силен ефект върху производителността. Промяната на нивото на регистриране на TRACE може да доведе до обхождане на JBossAS. Промяната му в ГРЕШКА (или ПРЕДУПРЕЖДЕНИЕ) може да ускори нещата драстично.

По подразбиране JBoss влиза в конзолата и server.log и по подразбиране използва ниво "INFO".

Помислете дали да не влизате в System.out (все пак може да искате да го пренасочите, за да уловите JVM грешки)

Помислете за промяна на нивото на регистрационния файл на ГРЕШКА. Не забравяйте, че JBoss наблюдава конфигурационния си файл log4j за промени и винаги можете да промените конфигурацията по време на изпълнение.

Добавете филтър за категории за вашата йерархия на Java клас.