Używam CF 9.0.1 w Ubuntu na „średniej” instancji Amazon EC2. CF przerywa się okresowo (kilka razy dziennie ... ale w szczególności nie jest izolowany do godzin szczytowego użytkowania). W takich czasach bieganieTop dostaje to (lub coś podobnego):

PID     USER    PR  NI  VIRT    RES     SHR S   %CPU    %MEM    TIME+COMMAND
15855   wwwrun  20  0   1762m   730m    20m S   99.3    19.4    13:22.96 coldfusion9

Więc oczywiście zużywa większość zasobów serwera. Następujący błąd pojawił się w moim pliku cfserver.log na początku każdego przejęcia:

java.lang.RuntimeException: Request timed out waiting for an available thread to run. You may want to consider increasing the number of active threads in the thread pool.

Jeśli ucieknę/ opt / coldfusion9 / bin / stan coldfusion, Dostaję:

Pg/Sec  DB/Sec  CP/Sec  Reqs  Reqs  Reqs  AvgQ   AvgReq AvgDB  Bytes  Bytes 
Now Hi  Now Hi  Now Hi  Q'ed  Run'g TO'ed Time   Time   Time   In/Sec Out/Sec
0   0   0   0   -1  -1  150   25    0     0      -1352560      0      0

W administratora podUstawienia serwera> Strojenie żądań, ustawienie dlaMaksymalna liczba jednoczesnych żądań szablonów ma 25 lat. Więc to ma sens. Mogłem po prostu zwiększyć pulę wątków, aby pokryć te skoki obciążenia. Mógłbym to zrobić 200. (co zrobiłem teraz jako test.)

Istnieje jednak również ten plik/opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/jrun.xml. Niektóre z ustawień wydają się być w konflikcie. Na przykład brzmi:

<service class="jrunx.scheduler.SchedulerService" name="SchedulerService">
  <attribute name="bindToJNDI">true</attribute>
  <attribute name="activeHandlerThreads">25</attribute>
  <attribute name="maxHandlerThreads">1000</attribute>
  <attribute name="minHandlerThreads">20</attribute>
  <attribute name="threadWaitTimeout">180</attribute>
  <attribute name="timeout">600</attribute>
</service>

Które a) ma mniej aktywnych wątków (co to oznacza?), Oraz b) ma max wątków, które przekraczają jednoczesny limit żądań ustawiony w admin. Więc nie jestem pewien. Czy te niezależne konfiguracje wymagają ręcznego dopasowania? Albo jestjrun.xml plik powinien być napisany przez administratora CF, gdy wprowadzane są zmiany? Hmm. Ale może to jest coś innego, bo przypuszczalnie CF Scheduler powinien używać tylko podzbioru wszystkich dostępnych wątków, prawda? ... więc zawsze mielibyśmy jakieś wątki dla prawdziwych użytkowników na żywo? Mamy to również tutaj:

<service class="jrun.servlet.http.WebService" name="WebService">
  <attribute name="port">8500</attribute>
  <attribute name="interface">*</attribute>
  <attribute name="deactivated">true</attribute>
  <attribute name="activeHandlerThreads">200</attribute>
  <attribute name="minHandlerThreads">1</attribute>
  <attribute name="maxHandlerThreads">1000</attribute>
  <attribute name="mapCheck">0</attribute>
  <attribute name="threadWaitTimeout">300</attribute>
  <attribute name="backlog">500</attribute>
  <attribute name="timeout">300</attribute>
</service>

Wygląda na to, że zmieniło się, gdy zmieniłem ustawienie CF Admin ... może ... ale to jestactiveHandlerThreads który odpowiada mojemu nowemu ustawieniu maksymalnych równoczesnych żądań ... zamiastmaxHandlerThreads, która znów go przekracza. Wreszcie mamy to:

<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">
  <attribute name="activeHandlerThreads">200</attribute>
  <attribute name="minHandlerThreads">1</attribute>
  <attribute name="maxHandlerThreads">1000</attribute>
  <attribute name="mapCheck">0</attribute>
  <attribute name="threadWaitTimeout">300</attribute>
  <attribute name="backlog">500</attribute>
  <attribute name="deactivated">false</attribute>
  <attribute name="interface">*</attribute>
  <attribute name="port">51800</attribute>
  <attribute name="timeout">300</attribute>
  <attribute name="cacheRealPath">true</attribute>
</service>

Nie jestem więc pewien, które (jeśli w ogóle) z nich powinienem zmienić i jaki jest dokładnie związek między maksymalnymi żądaniami a maksymalnymi wątkami. Ponadto, ponieważ kilka z nich zawiera listęmaxHandlerThreads jako 1000 zastanawiam się, czy powinienem ustawić maksymalne jednoczesne żądania na 1000. Musi istnieć jakiś górny limit, który zależy od dostępnych zasobów serwera ... ale nie jestem pewien, co to jest i naprawdę nie chcę bawić się nim, ponieważ jest to środowisko produkcyjne.

Nie jestem pewien, czy w ogóle dotyczy tego problemu, ale kiedy uruchamiamps aux | grep coldfusion Otrzymuję następujące informacje:

wwwrun   15853  0.0  0.0   8704    760    pts/1     S   20:22   0:00 /opt/coldfusion9/runtime/bin/coldfusion9 -jar jrun.jar -autorestart -start coldfusion
wwwrun   15855  5.4 18.2   1678552 701932 pts/1     Sl  20:22   1:38 /opt/coldfusion9/runtime/bin/coldfusion9 -jar jrun.jar -start coldfusion

Zawsze są te dwa i nigdy więcej niż te dwa procesy. Nie wydaje się więc, aby istniała relacja jeden-do-jednego między procesami a wątkami. Pamiętam z instalacji MX 6.1 przez wiele lat utrzymywałem, że dodatkowe procesy CF były widoczne na liście procesów. Wydawało mi się wtedy, że mam proces dla każdego wątku ... więc albo się myliłem, albo coś jest zupełnie inne w wersji 9, ponieważ raportuje 25 uruchomionych żądań i pokazuje tylko te dwa procesy. Jeśli pojedynczy proces może mieć wiele wątków w tle, zastanawiam się, dlaczego mam dwa procesy zamiast jednego? ... po prostu ciekawy.

W każdym razie eksperymentowałem podczas komponowania tego postu. Jak wspomniano powyżej, dostosowałem maksymalne jednoczesne żądania do 200. Miałem nadzieję, że to rozwiąże mój problem, ale CF ponownie uległ awarii (raczej zrzucił i żądania przekroczyły limit czasu ... tak skutecznie "rozbił się"). Tym razem top wyglądał podobnie (nadal zużywa ponad 99% procesora), ale status CF wyglądał inaczej:

Pg/Sec  DB/Sec  CP/Sec  Reqs  Reqs  Reqs  AvgQ   AvgReq AvgDB  Bytes  Bytes
Now Hi  Now Hi  Now Hi  Q'ed  Run'g TO'ed Time   Time   Time   In/Sec Out/Sec
0   0   0   0   -1  -1  0     150   0     0      0      0      0      0

Oczywiście, ponieważ zwiększyłem maksymalne jednoczesne żądania, zezwalało to na jednoczesne uruchamianie większej liczby żądań ... ale nadal maksymalizowało zasoby serwera.

Dalsze eksperymenty (po ponownym uruchomieniu CF) pokazały mi, że serwer stał się bezużyteczny po około 30-35 „Reqs Run'g”, a wszystkie dodatkowe żądania zmierzały do ​​nieuniknionego limitu czasu:

Pg/Sec  DB/Sec  CP/Sec  Reqs  Reqs  Reqs  AvgQ   AvgReq AvgDB  Bytes  Bytes
Now Hi  Now Hi  Now Hi  Q'ed  Run'g TO'ed Time   Time   Time   In/Sec Out/Sec
0   0   0   0   -1  -1  0     33    0     0      -492   0      0      0

Jest więc jasne, że zwiększenie maksymalnych jednoczesnych żądań nie pomogło. Domyślam się, że chodzi o to: z czym tak ciężko się boryka? Skąd pochodzą te kolce? Wybuchy ruchu? Na jakich stronach? Jakie wnioski są realizowane w danym momencie? Chyba potrzebuję więcej informacji, aby kontynuować rozwiązywanie problemów. Jeśli są długie żądania lub inne problemy, nie widzę ich w dziennikach (chociaż mam tę opcję zaznaczoną w admin). Muszę wiedzieć, które dokładnie żądania odpowiadają za te skoki. Każda pomoc byłaby bardzo mile widziana. Dzięki.

~ Dzień