-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ahojte,
nastal cas navysit diskovy prostor pro VPSky vsem clenum, protoze
nemalu uz prestalo 60 GB stacit.
Prosli jsme plan upgradu hw a soucasny stav, situace dovoluje dat
okolo 120 GB vsem se stejnymi parametry, co se zalohovani tyce, cili
to udelame rovnou tak - z 60 GB diskoveho prostoru navysujeme vsem na
120 GB.
Rozsireni probehne zitra, detaily popise Aither v mailu po mne.
Dve organizacni poznamky k tomu - prvni -> kdo mate diskovy prostor
navic a ponovu se vejdete do 120G, samozrejme nebude treba dal nic
doplacet; druha -> prosim vas, kdo mate produkcni data na NASu a po
upgradu se najednou vejdou na VPS filesystem, presunte ta data z NASu
na VPS - jednak usetrime zbytecnou sitovou zatez a jednak zvedneme
spolehlivost aplikace, ktera visi na dostupnosti nodu a jeste NASu k tom
u.
/snajpa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlZprxsACgkQgRwOVqYrsFW/PgD8DhQM5YSNPBDtUCDLeozJ77yH
GNPq1GR3WYzNQiRB63oA/2LPQjhbLlb6r6vuI+bfhCJzsm6oWEQd3zu7aDTw2R+G
=+zdq
-----END PGP SIGNATURE-----
Ahoj,
mám tady jeden server kde je cca 35k lidí za vteřinu. Běží tu nginx + php fpm a mysql db. V nginxu jsem rozjel microcache, což hodně ulevilo zátěži serveru. Nicméně, mám problém s PHPkem. FPM běží přes TCP (zkoušel jsem i unix socket nicméně bylo to pomalější a docházelo ke stejnému problému). Dle error logu dochází k těmto chybám:
2015/12/01 23:26:56 [error] 27043#0: *122476 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 188.114.98.51, server: xxx request: "GET /xxx/xxxx/xxx HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "xxxx", referrer: "http://xxxxx"
2015/12/01 23:26:56 [error] 27032#0: *124368 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 188.114.99.50, server: xxxxxx, request: "GET /xxxxx/xxxxx HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "xxxxx", referrer: "xxxxx"
a sype to tam docela drsně. Jak vypnu kešování v nginxu load vyskočí, třeba i na 500, těch chyb PHPka je méně ale jsou tam pořád.
Konfigurace FPM pro pool toho webu je:
[web1]
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
listen.owner = web1
listen.group = client0
listen.mode = 0660
listen.backlog = 65536
user = web1
group = client0
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slowlog-web1.log
pm = dynamic
pm.max_children = 7000
pm.start_servers = 4000
pm.min_spare_servers = 2000
pm.max_spare_servers = 4000
pm.max_requests = 100
request_terminate_timeout = 60s
rlimit_files = 500000
rlimit_core = unlimited
catch_workers_output = yes
pm.status_path = /php-status
chdir = /
+ openbasedir, sessions save path. atp.
S těma hodnotama jsem se zkoušel různě hrát, nicméně to k vyřešení tohoto problému nepomohlo. Zkoušel jsem upravit i nějaké parametry jádra (local port range, tcp ack timeouty atp.) ale výsledek stejný. Dělá to i u unix socketu, což je mi právě zvláštní. Nginx konfigurace je:
user www-data;
worker_processes 80;
pid /run/nginx.pid;
# set open fd limit to 50000
worker_rlimit_nofile 100000;
events {
worker_connections 1024;
multi_accept on;
use epoll;
}
ve vhostu nic zvlastniho, jenom pro php:
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_intercept_errors on;
fastcgi_read_timeout 4m;
Dnes bude k tomuto server nový, pro rozdělení zátěže, ale jako fakt nevím jestli to má smysl ve stejné konfiguraci, kvůli těm php chybám. Nenapadá Vás kluci, co s tím? Nebo případně návrh řešení, kterým bych nahradil tohle, při dvou serverech ? Přemýšlím nad MySQL M - M replikací, v DNS round robin a GlusterFS pro data. Ale to phpko mi nedá spát. A dnes večer to už další nápor asi nedá.
Díky za rady a konzultace.
S pozdravem
Branislav Viest
Ahoj,
aktivace KVM je nyní zpřístupněna všem členům přes vpsAdmin.
Znamená to, že si lze ve VPS (OpenVZ kontejneru) vytvářet virtuální
stroje přes KVM, např. za pomoci libvirt, a provozovat tak libovolnou
verzi jádra nebo i jiný operační systém.
KVM bylo zařazeno k ostatním VPS features (jako iptables, TUN/TAP,
apod.), které jsou nastavitelné v detailu VPS. Jak přesně se dá KVM s
libvirt použít je popsáno v KB [1].
[1] https://kb.vpsfree.cz/navody/vps/kvm
Jakub
Ahoj,
chci vás všechny pozvat na konferenci DevConf.cz 2016, největší akci o vývoji open-source software ve střední Evropě. Do konce měsíce máme otevřené přihlašování přednášek a workshopů. Pokud máte zajímavé téma a chcete ho sdílet s mezinárodním publikem, prosím vyplňte přihlášku [0].
Zároveň vás chci poprosit o sdílení pozvánky na Devconf.cz 2016 mezi vašimi kolegy a kamarády. Akce je otevřena pro všechny a rádi uvítáme přednášející z různorodých komunit zabývající se vývojem open-source software.
Více informací naleznete na našem webu [1] či na sociálních sítích [2, 3, 4, 5].
[0] http://www.devconf.cz/cfp
[1] http://www.devconf.cz/
[2] https://www.facebook.com/events/847514902012853/
[3] https://plus.google.com/events/cn14iev6uhl9ctm2fsr1pbvffa4
[4] https://lanyrd.com/2016/devconfcz/
[5] https://twitter.com/devconf_cz
Děkuji
S pozdravem a přáním pěkného dne
Jan Bleha ■ Community coordinator ■ Red Hat Czech s.r.o.
Mob.: +420 702 153 774 ■ Tel.: +420 532 294 537
Purkyňova 99/71 ■ 612 45 Brno ■ Czech Republic
IC: 27690016 ■ www.cz.redhat.com
The future is coming... Define it!
DevConf.cz/cfp
twitter.com/devconf_cz
ahoj je uz nekdo na miste?
ja se zrovna jdu ubytovat.
tomas
--
*quar | www.quar.cf <http://www.quar.cf>*
*html, python, node.js, php coder and sysadmin*
Ahoj všem,
ve čtvrtek budu přespávat v Praze a budu mít volný večer (nevyplatí
se mi před cestou do Brna vracet se domů). Byli byste někdo pro se
sejít? Jen tak volně, sraz někde v hospodě, probereme život, Linux i
servery a další důležitá témata :-).
--
Petr Krčmář
vpsFree.cz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ahojte,
pro ty, kdo mate vic, nez jednu VPS mame dobrou zpravu - rozbehali
jsme podporu GRE tunelu v kontejnerech, takze muzete vesele tunelovat :)
Petr to pekne sepsal na wiki, viz [1].
Jedinou muskou, co se tomu da vytknout, je zatim absence podpory
IPSecu, ktera je potreba nastesti az v momente, kdy byste chteli
tunelovat mezi VPS u nas a venkovnim svetem - jelikoz my mame sit
zabezpecenou tak, ze se traffic mezi VPS odposlouchavat neda nijak a
mezi datacentry nam IPSec bezi na paternich routerech (HW akcelerovane
navic :)).
[1] https://kb.vpsfree.cz/navody/server/gre
/snajpa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlY55wEACgkQgRwOVqYrsFWoSQD8DyHnBsJQE2HbCQgooAYgFmOJ
9mKIYbCcYXe14PKvcj8A/jUNBfZ3w8LIgPrkzWX+rNGhdxDWnyc8du+zMem6J265
=BPGI
-----END PGP SIGNATURE-----
