Planlagt arbejde på serveren

[NickyThomassen]

Hej alle

Som nogen nok har set, så er vi plaget af midlertidige fejl af typen "504 Gateway Timeout" som dukker op med jævne mellemrum. Anders og jeg har ikke kunne løse problemet med det software vi bruger nu, så et skift til noget andet er planlagt til lørdag d.4/6 kl.13. Arbejdet vil give nedetid og ustabil hjemmeside i 1-2 timer.

Når der er skiftet software bliver det annonceret i toppen af forummet, så I ved at hjemmesiden kan bruges igen.

Vi beklager generne men håber på at de midlertidige fejl forsvinder.

For de teknisk interesseret er det samspillet imellem nginx og php5-fpm der ikke virker ordentligt. I hvad der må være mindst 99.99% af gangene når php5-fpm skal lave en side virker det fint, imens de resterende gange resulterer i at en worker hos php5-fpm låser. Vi har ikke kunne få nogen af de 2 programmer til at logge fejlen, så vi skifter til Apache og ser om den virker med php5-fpm. Ellers skifter vi også php5-fpm ud med php5.

På vegne af administratorne, Nicky

[lath]

Hej alle

Som nogen nok har set, så er vi plaget af midlertidige fejl af typen "504 Gateway Timeout" som dukker op med jævne mellemrum. Anders og jeg har ikke kunne løse problemet med det software vi bruger nu, så et skift til noget andet er planlagt til lørdag d.4/6 kl.13. Arbejdet vil give nedetid og ustabil hjemmeside i 1-2 timer.

Når der er skiftet software bliver det annonceret i toppen af forummet, så I ved at hjemmesiden kan bruges igen.

Vi beklager generne men håber på at de midlertidige fejl forsvinder.

For de teknisk interesseret er det samspillet imellem nginx og php5-fpm der ikke virker ordentligt. I hvad der må være mindst 99.99% af gangene når php5-fpm skal lave en side virker det fint, imens de resterende gange resulterer i at en worker hos php5-fpm låser. Vi har ikke kunne få nogen af de 2 programmer til at logge fejlen, så vi skifter til Apache og ser om den virker med php5-fpm. Ellers skifter vi også php5-fpm ud med php5.

På vegne af administratorne, Nicky

imens de resterende gange resulterer i at en worker hos php5-fpm låser.

Så der opstår altså enten en deadlock eller en livelock. Problemet må så være i PHP fortolkeren. Det kunne være interessant om PHP fortolkerens datastrukturer er thread safe, hvis fortolkeren bruger mere end en tråd.

Problemet kan muligvis også være at antallet af file descriptors er for lavt - der sker "spændende" ting når antallet er for lavt.

Blandt andet kan man ikke åbne/læse/skrive til filer, og man kan ikke tage imod indkomne netværksforbindelser - HTTP/HTTPS kører oven på TCP. Her kunne det så muligt at man godt kan åbne en netværksfobindelse, men der mangler fil desciptors til at fuldføre arbejdet.

Man mister også fil descriptors hvis man glemmer at lukke ressourcer rigtigt ned - CLOEXEC lukker automatisk når en process afslutter, men en FastCGI process lukker normalt aldrig ned.
At miste fil descriptors kan selvfølgelig både ske i PHP fortolkeren såvel som med PHP scripts.

• Linux: Find Out How Many File Descriptors Are Being Used
  http://www.cyberciti.biz/tips/linux-procfs-file-descriptors.html
• Linux Increase The Maximum Number Of Open Files / File Descriptors (FD)
  http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/

/Lars

[NickyThomassen]

Så der opstår altså enten en deadlock eller en livelock. Problemet må så være i PHP fortolkeren. Det kunne være interessant om PHP fortolkerens datastrukturer er thread safe, hvis fortolkeren bruger mere end en tråd.

Problemet kan muligvis også være at antallet af file descriptors er for lavt - der sker "spændende" ting når antallet er for lavt.

Mange tak for forslagene. Det første kan jeg ikke umiddelbart svarer på (andet end at det burde PHP være, inklusiv php5-fpm), men det andet ser ikke ud til at være problemet

Kode: Vælg alt

[titanus@ubuntu:/home/titanus]$
lsof | wc -l
512
[titanus@ubuntu:/home/titanus]$
sysctl fs.file-max
fs.file-max = 98956

Thread safe er i øvrigt grunden til at Apache blive installeret igen. For om end ikke andet, så kan vi da køre en kopi af PHP's fortolker i hver Apache process. Ulempen er selvfølgelig ram-forbruget, så i første omgang får php5-fpm lov til at forblive aktiv og så kører vi Apache i threaded mode.

[Klaus Rasmussen]

Wow, har altid fundet det utrolig smukt at se fagfolk arbejde.

[lath]

Hvis problemet statistisk set altid opstår efter T tid, så findes der er en god workaround omkring problemet.
Teknikken kan bruges mod alle slags problemer hvor en/flere ressource)r) langsomt bliver ædt op af en process.
Teknikken har jeg fra Google.

Man har 2 ressourcer A, og B: Her er det så 2 PHP fortolkere, der kører i hver deres process.
Web serveren kender kun proxyen som en PHP fortolker, selvom proxyen kun kan sende TCP trafik videre til process A, eller B, som er en PHP fortolker.

Proxyen fungerer således:

1. når proxyen starter op:
   
   • Proxyen starter process A, og process B.
   • Til at starte med så er process A den aktive process, og B er den inaktive process.
   • Når der er en hul igennem (med TCP) til process A og process B, så leder proxyen trafikken til process A.
2. Før T tid er gået:
   
   • Proxyen skifer aktiv process: Process B er nu den aktive process, og A er den inaktive process.
   • Proxyen tager livet af process A, og genstarter process A
3. Herefter gentages mønsteret (punkt 2), hvor der skiftes imellem hvilken process der er den aktive.

Proxyen kan antage at den inaktive process er færdig med sit sidste HTTP response på en brugers HTTP request, når der ikke kommer mere TCP trafik, samt en en tidsforsinkelse på F tid, hvor F er lidt mere en den tid som PHP forolkeren maximum er om at behandle et HTTP request.

Proxyen er ansvarlig for at sætte svar for process A, og B i en svar kø, så svar ikke mixes sammen.

Databasen (eller et andet program) bliver nødt til at være den ressource, der holder styr på om en bruger er logget ind eller ej, for ellers skal alle brugere logge ind igen hver gang proxyen skifter process.

/Lars

[AJenbo]

Det er desværre ikke tilfældet, det virker heller ikke til at være pr. antal besøgende. Mulighvis noget med det aktuelle load.

[Dan Hansen]

Jeg får en anden fejl: "502 Bad Gateway"

Ved ikke om det gør nogen forskel, men så ved I det

502.jpg (33.86 KiB) Vist 1864 gange

[AJenbo]

Ja, det er den fejl der kommer når serveren låser. Vi håber vi kan få det løst i morgen.

[Dan Hansen]

Ok. I første indlæg står der nemlig "504 Gateway Timeout"

[AJenbo]

Det kan også være 503, det kommer an på hvor den er i processen.

[NickyThomassen]

Jeg får en anden fejl: "502 Bad Gateway"

Ved ikke om det gør nogen forskel, men så ved I det

Tak for at nævne det, for det kunne sagtens have gjort en forskel

500-serien af svar-koder på en webserver er dog ens et godt stykke hen af vejen, og især 502 og 504 er ret ens. Set fra den besøgendes synspunkt er alle svar-koder i 500-serien helt ens: De er serverfejl som den besøgende ikke kan gøre noget for at løse.

De mest almindelige fejl i 500-serien er fejl 500 som er en uventet fejl der ikke kan beskrives af de andre fejlkoder i 500-serien, fejl 502 hvor det program der skal omdanne koden (PHP, Perl, Python, C ... ) til en korrekt hjemmeside giver et forkert svar og så fejl 504 hvor der slet ikke kommer noget svar fra det program der skal omdanne koden.

Iøvrigt er svar-koder i 100-serien OK koder, 200-serien er forskellige typer af fortsæt-koder, 300-serien er omdirigeringer, 400-serien er fejlkoder hvis noget ikke blev fundet eller den besøgende ikke har adgang og 500-serien er så til server-fejl. Udover kodens nummer, så hører der også en tekst med så koden er nemmere at forstå for mennesker. Således er den fulde 200-kode "200 - OK", 301 er "301 - Flyttet permanent", 403 er "403 - Adgang nægtet" og så fremdeles.

Selvom de fleste tjenester på internettet som mail, web, ftp osv osv alle bruger svar-koder, så varierer de fra tjeneste til tjeneste hvad de betyder omend der er visse sammenfald. Hvis en mailserver fx giver et svar i 500-serien så kan det både være serverfejl eller en afvisning af e-mail'en fordi den ligner spam. Derfor kan mailservere give en 2-delt svar-kode også begynder tingende for alvor at blive indviklede.

[AJenbo]

503 betyder at processen der skal danne siden ikke kunde findes.

Den første bruger der får fejlen får lov at vendte foreviget med en blank side, efterfølgende besøgende vil blive mød med en fejl 50x

[Kurt Christensen]

Hip hip hurra!

[NickyThomassen]

Én stk. opdatering gennemført uden problemer.

Vi bruger stadig php5-fpm så nu må tiden vise om Apache giver færre problemer end nginx. Eftersom vi aldrig fik fundet fejlen er det dog på ingen måde sikkert at nginx havde noget med problemet at gøre.

Ifølge SSL Labs modtager hjemmesiden stadig en A+ mærkning
https://www.ssllabs.com/ssltest/analyze ... .21.102.92

Jeg sammenlignede også hastigheden før og efter skiftet

Kode: Vælg alt

Med nginx
ab -n 50 -c 1 https://ubuntudanmark.dk/
...
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      131  156  22.3    155     211
Processing:    91  107  19.9     95     160
Waiting:       82   94  14.7     86     135
Total:        222  263  30.6    256     328


ab -n 50 -c 1 https://ubuntudanmark.dk/forum/
...
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      131  157  22.1    157     200
Processing:   613  682  45.3    679     811
Waiting:      528  581  35.2    581     695
Total:        750  839  45.3    843     952

Med Apache
ab -n 50 -c 1 https://ubuntudanmark.dk/
...
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      130  147  13.8    143     172
Processing:    91  102  10.8     97     126
Waiting:       41   51  10.7     44      75
Total:        221  250  22.2    248     294


ab -n 50 -c 1 https://ubuntudanmark.dk/forum/
...
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      130  160  28.6    150     234
Processing:   560  648  89.5    632    1166
Waiting:      477  545  90.1    517    1081
Total:        710  808  92.5    795    1301

[AJenbo]

Hastigheden ser jo fin ud, min mistanke er dog stadig på fpm, men den er jo et krav med nginx