abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 12:33 | Humor

Byl vydán remake filmu Ghost in the Shell. Tentokrát v Bashi. Zhlédnout lze online na "ssh ghost@theshell.xyz" [Hacker News].

Ladislav Hagara | Komentářů: 3
včera 20:40 | Zajímavý článek

Lukáš Růžička v článku S Hydrogenem za lepší rytmus aneb bubeníkem snadno a rychle na MojeFedora.cz představuje automatického bubeníka s názvem Hydrogen (Wikipedie): Hydrogen je velmi vydařený program, který rozhodně nesmí chybět ve výbavě žádného linuxového muzikanta. Umožňuje nejen vytváření jednoduchých bicích doprovodů, ale také sofistikované programování bicích a perkusí, jehož výsledek se naprosto vyrovná drahým

… více »
Ladislav Hagara | Komentářů: 7
včera 13:55 | Zajímavý projekt

UPSat (Twitter) je první open source nanodružice (CubeSat). Jedná se o společný projekt nadace Libre Space Foundation a University of Patras. Repozitáře projektu jsou k dispozici na GitHubu. Pod Libre Space Foundation patří také projekt SatNOGS (zprávička), projekt globální sítě open source pozemních satelitních stanic, vítězný projekt soutěže The Hackaday Prize 2014. UPSat je součástí mise QB50 (Twitter). ID UPSatu je GR02. GPS přijímač na UPSatu je od české společnosti SkyFox Labs. Součástí mise QB50 je i česká nanodružice VZLUSAT-1 s ID CZ02.

Ladislav Hagara | Komentářů: 4
21.4. 15:00 | Komunita

V diskusním listu Thunderbird planning vývojáři poštovního klienta Thunderbird řeší, zda by nebylo možné budoucí Thunderbird postavit nad webovými technologiemi, tj. nad Electronem, stejně jako například Nylas Mail. Gecko, nad kterým je Thunderbird postaven, se má hodně změnit. V plánu je odstranění vlastností, které Firefox už nepotřebuje, ale Thunderbird je na nich závislý [Hacker News, reddit].

Ladislav Hagara | Komentářů: 88
21.4. 10:22 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 299 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich. V Oracle MySQL je opraveno 39 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 11 z nich.

Ladislav Hagara | Komentářů: 7
21.4. 10:00 | Pozvánky

V úterý 25. dubna proběhne další Prague Containers Meetup. Přijďte se nechat inspirovat jak zlepšit build/delivery pipeline vašich kontejnerových aplikací.

little-drunk-jesus | Komentářů: 2
20.4. 21:33 | Komunita

Na Launchpadu se objevilo kódové jméno následující verze Ubuntu. Ubuntu 17.10 bude Artful Aardvark (mazaný hrabáč) [OMG! Ubuntu!].

Ladislav Hagara | Komentářů: 11
20.4. 20:11 | Zajímavý software

MojeFedora.cz informuje, že společnost Nylas oznámila vydání verze 2.0 poštovního klienta Nylas Mail (původně Nylas N1), která již plně podporuje Linux. Obchodní model společnosti je tzv. open core. Samotný klient je open source, ale uživatel si musí připlatit za některé pokročilé funkce. V základu se lze připojit k GMailu nebo libovolnému účtu přes IMAP. Podpora Exchange je pouze v placené verzi. Klient je napsaný nad Electronem.

Ladislav Hagara | Komentářů: 12
20.4. 15:55 | Zajímavý článek

České centrum pro investigativní žurnalistiku (ČCIŽ) publikovalo na svých stránkách článek s názvem Je česká státní správa „rukojmím Microsoftu“?. Drtivá většina české veřejné správy je závislá na výrobcích softwarového gigantu Microsoft – a nijak zvlášť jí to nevadí.

Ladislav Hagara | Komentářů: 21
20.4. 02:48 | Nová verze

Google Chrome 58 byl prohlášen za stabilní. Nejnovější stabilní verze 58.0.3029.81 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo 29 bezpečnostních chyb. Mezi nimi i chyba umožňující phishing s unicode doménami.

Ladislav Hagara | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (4%)
 (35%)
 (0%)
 (7%)
 (45%)
 (9%)
Celkem 280 hlasů
 Komentářů: 32, poslední dnes 12:24
    Rozcestník

    Dotaz: Problém - MySQL ve vysoké záteži

    10.5.2014 00:24 LuRy | skóre: 12
    Problém - MySQL ve vysoké záteži
    Přečteno: 668×

    Zdravím, řeším problém s MySQL (Percona) kdy ve vysoké zátěži se začnou kupit mysql procesy a nejčastěji se stavem Waiting for query cache lock, zkoušel jsem s tím experimentovat a snížit na 512MB ale problém přetrvává jak se navýší traffic jde to do kopru.
    Problém obvykle nastane kdy se na serveru objeví traffic 30 přístupů na web za vteřinu cca 1000-1500 za minutu. Do té doby je zpracování 8 sql dotazů obvykle do 10ms maximálně, poté se zvednou na 200-800 někdy i více což je už dost nepříjemné.
    Kdyz query cache vypnu zacne se neprijemne zvedat odezva na disky a dle atop lita "busy" chvilkama 70-99%.
    Efektivita zaple query cache dle udaju co udava mysql je 40-50%

    - Disky na 1. serveru jsou v konfiguraci 8x SAS 10k RPM v 10 RAIDu 4stripping+4mirror.
    - Koncept je 2 servery
    - 1. HAProxy (pro apache+fpm na jednom i druhem serveru, MySQL), MySQL, nginx pro staticky obsah, redis-server
    - 2. apache+fpm, mysql vzdalene na haproxy ktera preda pozadavek mysql serveru (pripraveno pro load balancing pokud bude 3ti server, spojeni pres haproxy nebo naprimo na tcp nema vliv na tento problem), server temer nesaha na disk, data pres nfs4, cache aplikace resena pomoci shm uloziste a redis-server v pameti bez aof

    Výše zmíněný problém doprovází zvýšený počet spojení ve stavu TIME_WAIT okolo 50tis celkove, přes 20tis pouze 3306 port

    System debian 7.5, Kernel 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64
    Mysqlmonlite vypis - https://static.chatujme.cz/mysqlmon1.txt
    sysctl vypis - https://static.chatujme.cz/sysctl.txt (sysctl.conf + komplet sysctl -a vypis nize)

    MySQL server jsem v noci upgradoval na 5.6 a query cache snížil na 512MB ale problém přetrvává dále (mysqlmonlite je ze včerejška ještě pro 5.5 s 2GB query cache.

    Předem díky za každou nápomocnou radu, mám pocit,že jsem něco nastavil špatně protože před 14 dny to bylo v pohodě a návštěvnost se nějak výrazně nenavýšila

    LuRy

    Odpovědi

    10.5.2014 15:02 Matlák
    Rozbalit Rozbalit vše Re: Problém - MySQL ve vysoké záteži
    1] možná by bylo vhodné dotaz zařadit spíše do databázové poradny? Tam se asi spíš dočkáš odpovědi.

    2] Velikost query_cache není jediná věc. Důležitý je i počet queries. Já třeba na mašině s 128G RAM používám nastavení 256M+50k a prakticky se se stavem "Waiting for query cache lock" nesetkávám.

    3] Je dost důležité, o jaké dotazy jde. Pokud úplné odstavení query_cache vede k zatížení disků, asi by stálo za to zkontrolovat které dotazy to způsobují. Pak je možné u nich query_cache povolit místně (viz mysql_query_cache_type=2, select sql_cache) a nebo náležitě upravit ten PHP script co data čte aby si je laskavě zacachoval u sebe...
    10.5.2014 22:06 LuRy | skóre: 12
    Rozbalit Rozbalit vše Re: Problém - MySQL ve vysoké záteži
    No dobře tak asi změna. Ted je mysql server spící včetně disku (qcache vypnuta) a nakupují se spojení stejným způsobem akorat ne uz se stavem waiting for query cache lock ale ve stavu sleep ale to je vcelku normalni. dle meho je pricina toto (server 2.)

    netstat -tapn|grep TIME_WAIT|wc -l 54610

    netstat -tapn|grep ":3306" |grep TIME_WAIT|wc -l 11119

    netstat -tapn|grep ":6379" |grep TIME_WAIT|wc -l 34011

    Ted momentalne haproxy frontuje 400 pozadavku na web server kterej ma limit 200 a uz to je v tomhle stavu par minut obvykly. Takze to nakonec vypada na redis ze si po sobe neuklizi nebo ho neco nadmerne vytezuje .. nicmene krom apllikace samotny ho nic nevyuziva mimo navic jede jeste momentalne po lokalu (1. web server i redis je off) info tvrdi 130-150 klientu coz je neobvykly.

    Problem nejspis bude nekde jinde nez v mysql.. mysql zere disk pouze pri nabehu co jsem vypozoroval nez si nataha data do pameti pak uz je to v klidu. Nez jsem dopsal tuhle zpravu zkusil jsem vymenit redis pro session za memcached po socketu tak uvidim jsem s tim uz bezradnej docela nevim vubec ceho se chytnout protoze se nejak neda ani podle ceho chyntout .. Tyhle problemy to dela ve chvilich kdy na to navstevnost ani nevypada nebo to dela pri mensi navstevnosti v prubehu dne nez byla pri minulem totoznem problemu

    cat /etc/sysctl.conf
    net.ipv4.tcp_tw_recycle = 0
    net.ipv4.tcp_window_scaling = 1
    net.core.rmem_max = 16777216
    net.ipv4.tcp_rmem = 4096 87380 16777216
    net.ipv4.tcp_wmem = 4096        16384   16777216
    
    net.core.somaxconn = 65535
    net.ipv4.conf.all.send_redirects = 1
    net.ipv4.ip_nonlocal_bind = 1
    net.ipv4.tcp_abort_on_overflow = 0
    net.ipv4.tcp_fin_timeout = 20
    net.ipv4.tcp_keepalive_time = 300
    net.ipv4.tcp_max_orphans = 262144
    net.ipv4.tcp_max_syn_backlog = 65536
    net.ipv4.tcp_max_tw_buckets = 262144
    net.ipv4.tcp_mem = 200000    280000    300000
    net.ipv4.tcp_reordering = 3
    #
    #net.ipv4.tcp_rmem = 4096    87380    4120928
    net.ipv4.tcp_synack_retries = 3
    net.ipv4.tcp_syncookies = 1
    net.ipv4.tcp_syn_retries = 5
    net.ipv4.tcp_timestamps = 0
    #net.ipv4.tcp_tw_recycle = 0
    net.ipv4.tcp_tw_reuse = 1
    #
    #net.ipv4.tcp_wmem = 4096    16384    4120928
    
    net.ipv4.netfilter.ip_conntrack_max = 10485760
    net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 20
    net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 10
    net.netfilter.nf_conntrack_max = 10485760
    net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 30
    net.netfilter.nf_conntrack_tcp_timeout_time_wait = 15
    net.ipv4.ip_local_port_range=1025 65000
    #kernel.shmall = 2097152
    #kernel.shmmax = 2147483648
    #kernel.shmmni = 4096
    #kernel.sem = 250 32000 100 128
    fs.file-max = 209708
    net.core.netdev_max_backlog=4096
    #net.core.wmem_max = 229376
    net.ipv4.tcp_slow_start_after_idle = 0
    #net.netfilter.nf_conntrack_count = 131072
    #net.
    
    
    
    10.5.2014 22:28 LuRy | skóre: 12
    Rozbalit Rozbalit vše Re: Problém - MySQL ve vysoké záteži
    Moje hypoteza je takova ze phpko pri zpracovani skriptu se na necem zasekne (nejspis na zamcich u redisu) a pak se odsekne a mysqlce naserviruje napriklad 50-100 spojeni najednou proto se zvedali tak ty casy a query cache se invalidovala vicekrat nez by bylo zdravo ale ted je to vlastne podruznej problem uz .. Zatim jsem vymenil pro php sessions redis za memcache tak uvidim.. jediny co me trapi je to ze kdyz resetnu memcache tak vse zahodi a memcachedb je dle myho nazoru sebevrazda o nekolik kradu pomalejsi. Uvidim nejspis v prubehu zitrka kdy byva obvykle spicka k veceru

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.