[SuperMicro Serwer - prośba o opinię]

Wrzucam do koszyka serwer ale pierw chciałem zaczerpnąć informacji o producencie SuperMicro, wcześniej używałem Fujitsu i HP a SuperMicro aktualnie cenowo wychodzi b.dobrze. Poczytałem i jakościowo jest ok, produkują chyba nawet płyty dla Della? Jakieś opinie z praktyki?
Konfiguracja, którą sobie stworzyłem:
Xenon E-2226G 3.4G 12M
64Gb Ddr4
Kontroler pod Raid AOC-S3008L-L8I
WS2019 E
2x ssd 960gb
Zasilanie redundantne 

 

Docelowo obsługa softu z bazą pgsql. SSD spięte w raid 1. Pytanie dodatkowe czy baza przy raid 1 to spoko rozwiązanie bo zastanawiam się czy nie zabrać 4x ssd 480 i spiąć to w raid 10 na jednej partycji systemu a druga pod bazę. 

Aktualnie stara maszyna spięta jest w sprzetowy raid1 na dyskach satach i od ok 5 lat nie było z nimi problemów, ilość operacji IO raczej w stronę odczytu.

 

//Edit Tzn. ja jestem za raid10, ale budżetowo przy powyższej konfiguracji jestem już na styku a wrzucenie zamiast 4x 480 to wystrzeli cenę o ok 1k

 

[TTFB - poprawa czasu odpowiedzi]

7 minut temu, SiXwishlist napisał:

 

nie wiem jaka jest tego przyczyna ponieważ nie miałem takich problemów

jakby miał jakiś cache na wyniki dla domeny  po 30 minutach zrobiłem retest i wyniki były już ok

[TTFB - poprawa czasu odpowiedzi]

1 minutę temu, Poziomecki napisał:

A apache2+nginx? Ewentualnie litespeed.

aktualnie ta konfiguracja lata apach2.4+nginx

[TTFB - poprawa czasu odpowiedzi]

2 minuty temu, Mion napisał:

IMHO - Powinieneś jeszcze rozważyć całkowita rezygnację z Apacha, bo w tym układzie ngix  dla PHP odpytuje Apacha ten łączy sie z procesem FCGI, czyli  przelewanie z szklany do szklanki, apache trochę RAMU zabiera

 

rozważam i nawet to testowałem, ale wykrzaczyła się całkowicie strona przy serwowaniu backendu również przez ngixa  i zostawiam to na później jak Dev wyrobi się całkowicie z pracą. 

[TTFB - poprawa czasu odpowiedzi]

Mion, dzięki za dołączenie do dyskusji, ogólnie jak pisałem problem znaleziony = przy każdym wejściu na stronę odbywało się zapytanie o nowe art.   co niepotrzebnie wydłużało czas. 

 

// testowałem redisa i opcache - 

[TTFB - poprawa czasu odpowiedzi]

Jak wyżej pisałem, udało się znaleźć  gdzie jest błąd - jest w sekcji z artykułami która jak teraz widać jest pobierana z WP przy każdym zapytaniu. Usunięcie sekcji  oczywiście sytuacje zmieniło diametralnie, ttfb = 215ms, teraz task dla programisty aby to poprawić.

 

 Bardzo dziękuje Wam za pomoc!

 

// Jeszcze pytanie  o https://performance.sucuri.net/ ,

pokazuje przy każdym teście realne wyniki czy odświeża co jakiś czas? Widże ttfb na poziomie 3s gdzie inne narzędzia pokazują 150-210ms

[TTFB - poprawa czasu odpowiedzi]

przy -ttt 

https://pastebin.com/YDjM6RWX

 

Nie wiem czy o to chodziło, odpalam strace i muszę go przerwać ctrl+c bo danych jest naprawdę dużo, przy każdym wykonaniu 

// dobra widzę chyba że jednak to nie ten PID dla zapytania z serwisu o TTFB

 

Coś dziwnego znalazłem  w Da ustawione dla domeny mam pierwsze php na 7.0 i odpalając plik phpinfo z domeny jest wersja 7.0 ale zatrzymując proces z php5.6 strona pada na pysk z errorem 

ERR_TOO_MANY_REDIRECTS

 

Ok już chyba wiem co jest

Na autorskim skrypcie (php70) jest sekcja z artykułami pobiera przy pomocy API z WP (php56) artykuły, podejrzewam że przy każdym request jest wykonywane zapytanie do WP. Zaraz wyłączę sekcję i zobaczę czy coś da.

 

[TTFB - poprawa czasu odpowiedzi]

ok miałem kilka pidów dla php-fpm7 akurat z tej wersji korzystam przy tym serwisie, odpaliłem i jest dosyć obszernie 

https://pastebin.com/eY9viNea

 

-- dokładnie, WP na tym serwerze nie ma problemów - TTFB na poziomie 0.184 secs

 

[TTFB - poprawa czasu odpowiedzi]

sprawdzałem i nic, zarówno dla php5.6 i php7 pusty error log

[TTFB - poprawa czasu odpowiedzi]

Procesów oczywiście od groma, ale czasy bez zmian ;/ httpd-mpm.conf wleciał conf dla prefork i httpd-default.con wleciała reszta, reload i restart httpd były.

[TTFB - poprawa czasu odpowiedzi]

dziennie ok 5-6 tys. UU więc niewiele, szukałem  info na temat czy event/prefork/worker i gdzieś przeczytałem że w sumie event jest najbardziej elastyczny dlatego tak też ustawiłem, nie mam problemu z tym aby przejść na prefork. Wartości właśnie zmieniłem, przeładowałem, kolejne pomiary i sytuacja bez zmian

 

dla prefork mam coś takiego w configu

Cytuj

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    ServerLimit         450
    MaxRequestWorkers   450
    MaxConnectionsPerChild   10000
</IfModule>
 

za Twoją radą wówczas dla prefork server limit wynosi 15 ale w tym configu przydałoby się zapewne zwiększenie wartości.

//

Ok, ustawiony prefork, w configu dałem

MinSpareServers       350
    MaxSpareServers      450
    ServerLimit         800

 

czasy bez zmian.

[TTFB - poprawa czasu odpowiedzi]

ok, ogólnie jest to Apache z ngixem na reverse proxy - wcześniej był sam apach 2.4 - ta sama sytuacja w obu wypadkach.

Cytuj

Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/httpd"
 -D HAVE_SYSTEMD
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
 

 

i config dla Event:

  StartServers             6
    MinSpareThreads         32
    MaxSpareThreads        128
    ThreadsPerChild         64
    ServerLimit             32
    MaxRequestWorkers     2048
    MaxConnectionsPerChild   10000

Sprawdziłem też z Twojego urla - First Byte zaczyna się od 1.698s także jeszcze gorzej. 

Tak jak pisałem na przestrzeni jakiś 2-3 tygodni się pogorszyła sprawa 

[TTFB - poprawa czasu odpowiedzi]

48 minut temu, SiXwishlist napisał:

Odpal jeżeli możesz htop lub top w konsoli i powiedz mi ile pamięci ram jest wykorzystywane przez bazę danych. 

mysqltuner to fajne narzędzie lecz nie zawsze służy odpowiednią radą gdy na serwerze masz aplikacje różnego typy, Zresztą by zweryfikować wyniki mysqltuner potrzeba przynajmniej tygodnia obserwacji. Inna sprawa to czym testujesz odpowiedź serwera, równie dobrze problem może być ruch na sieci w DC który powoduje opóźnienie a sam serwer ma się bardzo dobrze. 

Dzięki za dołączenie do tematu :) Ogólnie według DA zarezerwowane jest dla mysqld 11.47 GB. Mysqltunera oczywiście używałem w dłuższych odstępach czasu i oczywiście zawsze sugerował zwiększenie pewnych parametrów które uprzednio były zmieniane przy jego sugestii. Testuje pingdoomtools z lok. Szwajcaria, Pagespeed ins.. i webpagetest lok. Warszawa i Berlin

 

według top

i iotop,

[TTFB - poprawa czasu odpowiedzi]

Dzięki za wskazówkę, w takim wypadku zabieram się za kolejne analizy 

[TTFB - poprawa czasu odpowiedzi]

jest  

[TTFB - poprawa czasu odpowiedzi]

Autorski i było już kilku Devów  więc każdy zostawił coś od siebie ;/

[TTFB - poprawa czasu odpowiedzi]

Witam, rozkładam już ręce bo brakuje mi pomysłów na optymalizacje czasu odpowiedzi, który w ostatnim okresie uległ pogorszeniu. 2-3 tygodnie temu oscylował w granicach 0.8s wcześniej udało się wyciągnąć 0.5s a teraz to 1.2s. Mimo optymalizacji przeróżnych parametrów dla bazy/ apacha php'a  ta wartość stoi w miejscu

- Mysql - MariaDb 10.1 , przetestowałem kilka konfiguracji, używałem mysqltuner'a etc. 

- Php  w wersji 7.0 - php-fpm + opcache
- Apache 2.4 + ngix na revers_proxy + HTTP2
Wszystko aktualne.  Wydaje mi się że ten zestaw powinien działać sensownie i dosyć szybko.

Serwerownia kylos.pl, 32gb ramu, ssd. Baza spora i tu obstawiałem problem ale dorzuciłem jej ramu do wykorzystania, zwiększyłem cache i niestety nic to nie dało. Zainstalowałem Munina w piątek, niestety to moje pierwsze analizy i jedynie co rzuciło mi się w oczy to spore wykorzystanie pamięci przez cache.  WP na tym samym serwerze bez problemów, skrypty ładują się szybko więc wszystkie znaki na niebie przekonują mnie do samego skryptu / bazy.

Miałby ktoś chwilę rzucić okiem chociażby na munina i może zauważy wąskie gardło ewentualnie potwierdzić moje przypuszczenia że to strona.

Pozdrawiam