Hector "marcan" Martin z Asahi Linuxu skončil jako upstream vývojář linuxového jádra. Štafetu po něm převzal Janne Grunau z Asahi Linuxu.
PlayStation Network (PSN) má již několik hodin, vlastně celou sobotu, masivní výpadek (Stav služby PSN, X).
Vývojáři open source storage platformy TrueNAS oznámili, že s verzí 25.04 s kódovým názvem Fangtooth končí TrueNAS CORE postavený na FreeBSD a TrueNAS SCALE postavený na Linuxu. Jejich společným pokračováním bude TrueNAS Community Edition postavený na Linuxu.
Mapy Google dnes slaví 20 let. Spuštěny byly 8. února 2005. Svět se přesunul od papírových map k digitálním. A ke Street View, Live View, Immersive View, …
Hector "marcan" Martin, vedoucí projektu Asahi Linux aneb Linux na Apple Siliconu, skončil jako upstream vývojář linuxového jádra. Se slovy "už nemám žádnou důvěru v proces vývoje jádra … další vývoj Apple/ARM bude pokračovat downstream" odstranil své jméno ze souboru MAINTAINERS. Důvodem jsou neshody kolem Rustu v linuxovém jádru [Hacker News, No rust code in kernel/dma, please.].
Mistral AI včera představil nový vylepšený Le Chat. Nově také jako aplikace pro iOS a Android.
Britské bezpečnostní orgány nařídily americké firmě Apple, aby vytvořila takzvaná "zadní vrátka", která by umožnila dostat se k šifrovanému obsahu uživatelů uloženému v cloudu. Tajné nařízení, vydané v lednu, vyžaduje plošný přístup k šifrovanému účtu jakéhokoliv uživatele přístrojů Apple kdekoliv na světě. Britské úřady tedy Apple nežádají pouze o asistenci s přístupem k účtu konkrétního uživatele, ale rovnou chtějí mít přístup ke všem účtům, kdykoliv budou chtít.
Byla vydána (𝕏) lednová aktualizace aneb nová verze 1.97 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.97 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Nedávno se povedlo do pdf souborů vložit Tetris a DOOM a po otevření příslušného pdf souboru v na Chromiu založeném webovém prohlížeči vybranou hru přímo v pdf spustit. LinuxPDF ukazuje, že do pdf lze vložit také RISC-V emulátor a rozběhnout Linux.
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
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.
Tiskni
Sdílej: