Puncte:0

Timp de răspuns lent când serverul este inactiv, timp de răspuns rapid când serverul este încărcat?

drapel dk

Rulez un server cu 40 fire / 125 GB RAM.

Serverul se bazează pe CentOS 7.

Am observat că timpul de răspuns al serverului este mai mare atunci când serverul este inactiv:

introduceți descrierea imaginii aici

Puteți vedea în captura de ecran aici că răspunsul serverului între orele 16:00 și 22:00 a fost mai scăzut decât în ​​alte ore.

M-am uitat la jurnalele și GoogleBot ne lovea la 4 solicitări/secundă în acel moment care a încărcat serverul. Majoritatea solicitărilor de la GoogleBot au fost 302 redirecționări (catalog mare de comerț electronic cu modificări zilnice ale produselor live).

introduceți descrierea imaginii aici

Aici puteți vedea debitul serverului - în perioadele în care serverul era ocupat, atunci timpii de răspuns erau mici.

Cum pot depana asta?

Ce cauzează asta?

Ar putea 302 redirecționări să fie mai ieftine decât cele 200 de răspunsuri care au denaturat datele?

Ar putea cache-ul (Redis / Opcache / APCu) să fie evacuat prea devreme, ceea ce provoacă recrearea memoriei cache în timpul inactiv?

În prezent rulăm: Apache 2.4 Proxy Nginx MySQL Redis Opcache APCu Elasticsearch

ACTUALIZAȚI:

Privind procesele separate, PHP ocupă cel mai mult timp:

introduceți descrierea imaginii aici

MySQL este oarecum corelat cu PHP, dar nu pe deplin:

introduceți descrierea imaginii aici

djdomi avatar
drapel za
Răspunde asta la întrebarea ta? [Mă puteți ajuta cu planificarea capacității mele?](https://serverfault.com/questions/384686/can-you-help-me-with-my-capacity-planning)
drapel dk
@djdomi aceasta nu este cu adevărat o întrebare despre capacitate - este o întrebare despre de ce atunci când serverul este inactiv, timpul de răspuns este mai mare decât atunci când serverul este încărcat. Ar putea exista anumite setări pe care ar trebui să le folosesc pentru a reduce timpul de răspuns când serverul este inactiv? Am vorbit cu tipul meu de la server și mi-a spus că s-ar putea datora faptului că cererile 302 sunt mai ieftine decât 200, deci poate fi interpretarea greșită a datelor din cauza cererilor ieftine 302.
Hagen von Eitzen avatar
drapel cn
Cauza este probabil cam așa: într-o stare ocupată, cele mai importante părți sunt deja stocate în cache în RAM de la cererea anterioară (directoare, fișiere statice, scripturi php, probabil chiar cod de octeți PHP și chiar interogări SQL), în timp ce în perioadele de inactivitate fiecare cerere poate fi nevoit să încarce aproape totul de pe disc.În cazul în care întregul dvs. *server* este un VM, poate fi chiar cazul că acest lucru necesită puțin timp pentru a obține și resurse
drapel dk
@HagenvonEitzen hmmmm, dar puteți vedea din grafice, nu este ca și cum ar fi o cantitate uriașă de timp care trece între stările ciudate de timp de răspuns scăzut și mare. Aș crede că graficele ar fi mult mai fine între tranziții. Serverul este echipat cu unități NVME și nu este chiar blocat de acestea (3500MB/s). Majoritatea datelor sunt deja în RAM și folosim doar aproximativ 70 GB din 125 GB.
drapel dk
FYI, acesta este un sistem baremetal cu unități NVME, 125 GB RAM, 2xCPU-uri / 40 fire.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.