Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
V našem ústavu máme linuxový login server 2x XEON, 2GB RAM.
Nějakých 300 uživatelů si na něm dělá leccos, nejvíc ale přístup
k poště IMAPem. Hodně jich má stovky MB mboxů nastřádaných za ta léta.
Hodně jich taky má soubor ~/mbox
ve stovkách MB. Nebo jiné velké poštovní soubory ve formátu mbox.
Používáme (zatím) WU imapd spouštěný pomocí xinetd
. Poslední dobou
přicházejí situace, že obsluha IMAP klientů je podstatně zpomalená, takže uživatelé si celkem právem stěžují. Stěžují si právem i ti, kteří mají poštu hezky roztříděnou do desítek nebo stovek malých mboxů, protože jim to
v těch kritických chvílích taky běhá pomalu. V následující samomluvě se budu snažit o analýzu problému, aniž bych dospěl k hotovému řešení.
Když udělám
na log, tak se mi zdá, že vidím příčinu problému. Mnozí klienti na to jdou tak, že
jakmile dostanou, co chtěli, ukončí IMAP relaci a během několika sekund se připojují
znovu. Slušný člověk by zůstal připojen a další požadavek
by poslal po pěti minutách. Ale tohle jsou většinou MS klienti, ti to takhle dělají. Nejsou sami, ani Squirrel Webmail si nedělá trvalé spojení.
grep 'imapd.*Login user=' | sort +6.0 -7.0
vmstat 1
v těch kritických chvílích ukazuje nevelké zatížení procesoru kolem 20% jedné CPU, nulovou stránkovací aktivitu, ale zato čtení z blokových zařízení
bo=15000 a víc. Nemýlím-li se, tohle znamená provoz 15MB/s čtení z disku
a ukazuje se, že se jedná o to diskové pole, na kterém je jak /var/spool/mail , tak uživatelské homesy. Při tom
opravdu neukazuje nic podezřelého, jenom stovky imapů.
ps -ef
Moje představa je taková, že opakované čtení poštovních souborů vede k mnoha přístupům na disk, takže buffery jádra už to nevyrovnají a systém skutečně fyzicky přistupuje na disky. Kde je to slabé místo nevím - snad přímo v jádře, když současně máme kolem 1000 context switchů za sekundu.
Nabízí se možnost použít jiný IMAP server. V debatním klubu cz.comp.linux jsem našel diskusi různých IMAP serverů. Thread začíná tady. Mohli bychom udělat pokus se serverem dovecot. Mohli bychom nechat dosavadní formát mbox, takže uživatelé by si třeba ani nevšimli a dál by si vesele grepem hledali, co před lety sami napsali. mbox zůstane mboxem, kdo ví jestli by to pomohlo. Co když nutným předpokladem k efektivnějšímu zpracování pošty je právě přechod na maildir? V tom případě bychom uživatelům museli nabídnout samozřejmě nástroj na převod uložené pošty do nového formátu, ale taky nějaký vyhledávač, který by nahradil dosavadní přímé hledání v mboxech.
Než se pustíme do vyměňování IMAP serveru, rád bych si promyslel ještě jiné možnosti.
Nešlo by třeba poradit jádru, aby si udělalo větší buffery? Škoda že nevím jak. To jádro je 2.4.21-297-smp4G #1 SMP .
Já myslím, že zdaleka největší zatížení pochází od počátečního čtení INBOXů. Kdyby IMAP připojení bylo trvalé, tohle by přestalo a zase by se to začalo chovat mravně. Takže bychom potřebovali front end
neboli
fake IMAP server
,
který by napoprvé přijal počáteční požadavek od klienta a jen by zprostředkoval komunikaci mezi klientem a základním démonem. Po vyřízení požadavku by ale spojení neukončil, nýbrž by pár minut vyčkal. A kdyby mezitím dostal požadavek od stejného klienta, odfiltroval by počáteční autentizační část a potom by teprve zprostředkoval komunikaci.
Na webu vidím pár IMAP front endů, ale vesměs jsou orientovány na pokročilejší funkce - totiž na rozhození zátěže na klastr. Případně na odfiltrování jen
autentizační části, ale ta nám to v našem případě nebrzdí (jak vidíme na nevelkém vytížení procesorů). Nějaký IMAP Front End
se nabízí i k MS Exchange. No jasně, proto se MS poštovní klienti můžou přetrhnout, jak zběsile posílají požadavky. Aby se hodně kupovaly Exchange a k nim potřebné tuny železa.
IMAP front end jednoduché konstrukce, jak jsem se ho právě pokusil specifikovat, jsem v Internetu kupodivu nenašel. Asi jsem vymyslel úplnou hloupost.
Tiskni Sdílej:
Kamarad google na dotaz co vi o imap proxy; odpovedel webem http://www.imapproxy.org kde lze najit - cituji :
What is the imapproxy?
The name says almost all you need to know. It proxies IMAP transactions between an IMAP client and an IMAP server. The general idea is that the client should never know that it's not talking to the real IMAP server.
Snad by Vam to mohlo pomoci, pri (velmi) zbeznem pohledu je to presne to co potrebujete.
Take je dobre zminit, ze cast uzivatelu ma svuj $HOME (resp. mailboxy z nej) umisten na jinem stroji a pristupuje se k nemu pres NFS. Muze to nejak ovlivnit vykon?
Drobna poznamka - muj osobni a nicim nepodlozeny nazor je to, ze by zlepseni odezvy pomohlo i to, aby se Maple poustel nekde jinde a ne na onom serveru. Jiste, je to SMP stroj, ale stejne...
Dalsi poznamka - nekdy pred cca. rokem jsem se snazil prinutit pine spolupracovat s maildirem a pokud si dobre pamatuju, tehdy to "oficialni" verze jeste neumela.
A konecne posledni poznamka - celkem zajimave mi pripada pristupovani na IMAP pres SSH tunel. Uzivatel nepouziva standardni TCP/SSL, ale pres SSH si "sam" pusti IMAP demona. Zrejme to pouziva naprosto minimalni pocet lidi, ale je to vcelku zajimava myslenka - umoznuje pouzivat SSH klice etc. Bylo by dobre, aby tahle moznost zustala zachovana (resp. na onom serveru jsem ji jeste nezkousel, takze vlastne nevim, jestli funguje).
Napřed děkuji za tip na imapproxy.org , tohle jsem myslím přesně potřeboval. Jinak podle mnoha názorů by nám pomohl jiný formát poštovních souborů. Každý jiný než klasický mbox bude lepší. Začneme si nějak hrát s formátem mbx. maildir se radši vyhneme, protože statisíce souborů každého ze stovek uživatelů, s tím by se docela špatně manipulovalo.
Začneme tou proxy. Jo a taky od xinetd přejdeme k démonovi. I když na tom vlastně nezáleží.