Letos se uskuteční již 11. ročník soutěže v programování Kasiopea. Tato soutěž, (primárně) pro středoškoláky, nabízí skvělou příležitost procvičit logické myšlení a dozvědět se něco nového ze světa algoritmů – a to nejen pro zkušené programátory, ale i pro úplné začátečníky. Domácí kolo proběhne online od 22. 11. do 7. 12. 2025 a skládá se z 9 zajímavých úloh různé obtížnosti. Na výběru programovacího jazyka přitom nezáleží – úlohy jsou
… více »Byla vydána nová verze 2.52.0 distribuovaného systému správy verzí Git. Přispělo 94 vývojářů, z toho 33 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
VKD3D-Proton byl vydán ve verzi 3.0. Jedná se fork knihovny vkd3d z projektu Wine pro Proton. Knihovna slouží pro překlad volání Direct3D 12 na Vulkan. V přehledu novinek je vypíchnuta podpora AMD FSR 4 (AMD FidelityFX Super Resolution 4).
Poštovní klient Thunderbird byl vydán v nové verzi 145.0. Podporuje DNS přes HTTPS nebo Microsoft Exchange skrze Exchange Web Services. Ukončena byla podpora 32bitového Thunderbirdu pro Linux.
U příležitosti státního svátku 17. listopadu probíhá na Steamu i GOG.com již šestý ročník Czech & Slovak Games Week aneb týdenní oslava a také slevová akce českých a slovenských počítačových her.
Byla vydána nová verze 9.19 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze například nový balíček BirdNET-Go, tj. AI řešení pro nepřetržité monitorování a identifikaci ptáků.
Byla vydána nová verze 3.38 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.10 souvisejícího programovacího jazyka Dart (Wikipedie).
Organizace Apache Software Foundation (ASF) vydala verzi 28 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Byl vydán Debian 13.2, tj. druhá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Google představil platformu Code Wiki pro rychlejší porozumění existujícímu kódu. Code Wiki pomocí AI Gemini udržuje průběžně aktualizovanou strukturovanou wiki pro softwarové repozitáře. Zatím jenom pro veřejné. V plánu je rozšíření Gemini CLI také pro soukromé a interní repozitáře.
Pokud máte pravidelné zálohy dat, a nejlíp ještě nastavíte řadič RAIDu, aby pravidelně kontroloval povrch, tak by to asi mělo být bezpečné. Čím jednodušší hardware a čím nižší spotřeba elektřiny, tím vyšší spolehlivost / delší životnost. Ostatně už jsem tady o tom jednou klábosil... Některé modely mají 8x SAS na bázi LSI 1068 (FreeBSD driver mpt), šlo by to rozjet se softwarovým RAIDem ve FreeBSD. Pozor na jeden kus co má 8x SAS2 LSI2008, pro ten ještě není podpora ani ve FreeBSD CVS (ostatně ani driver pro Windows na LSI webu).
V databázovém enginu a v operačním systému, na kterém databáze běží, můžete jistě ladit nastavení VM, velikost bufferů apod... nicméně základní věc, na které stojí a padá výkonnost databáze, je definice indexů na atributy=sloupce, podle kterých se vyhledává / pomocí kterých se propojují tabulky v dotazech. A taky konstrukce dotazů (to je větší "makačka na bednu"). Tím jste se zabýval? Nebo jste použil hotový "redakční systém", u kterého se předpokládá, že toto je v pořádku, a jeho střeva do těchto detailů neřešíte?
Přijde mi zajímavé, že potřebujete pokud možno dostat celou databázi do RAMky, aby to chodilo použitelně. To může znamenat dvě věci:
1) při špičkové zátěži (která je dána aktivitou uživatelů) disky prostě nestíhají, ani při pečlivé optimalizaci. Může to být dáno skutečně velkým počtem uživatelů.
2) špatná optimalizace indexů nebo dotazů
Rád slyším, že o vytížení procesoru máte představu. Máte v těch grafech taky vidět IOps disků? V této souvislosti, pokud někde chybí index, tak to bude zvyšovat zátěž jak disků, tak procesoru. Finta s indexem spočívá v tom, že držíte v RAMce především data "identifikátorových" sloupců, která jsou krátká, takže nezaberou moc místa, a lze je snadno organizovat do binárních stromů pro rychlé porovnávání/vyhledávání (jsou takto v RAMce organizována). Koncová data (dlouhé texty, bloby) se pak tahají podle potřeby z disku.
Tradičně se databáze skutečně do RAMky nevejde, může zabírat třeba o řád nebo o dva větší prostor na disku, než kolik má stroj RAMky. Pak už záleží na zátěži aplikace v poměru k IOps disků, jestli bude výsledná latence pro koncového uživatele subjektivně snesitelná, nebo k nepoužití. Fakt je, že u mnoha internetových aplikací pro masu uživatelů prostě není jiná šance, než držet v RAMce celou databázi. Disky pak poskytují víceméně perzistentní uložení dat pro případ výpadku napájení.
RAID nenahrazuje zálohy. Netuším, zda jste schopen zazálohovat nastojato celý systém, a zase ze zálohy obnovit - třeba Ghost tuším neumí UFS, ale dobrý admin dokáže zazálohovat a obnovit systém nastojato i holýma rukama z bootovacího instalačního CDčka Dobrý nápad je, zazálohovat si alespoň konfiguráky, které Vám daly hodně práce (pro urychlení případné reinstalace) a pak samozřejmě data - statický obsah webu a obsah databáze. Záloha by měla probíhat někam mimo server. Stačí třeba nějaký obyčejný SATA disk v externím USB rámečku - důležité je, aby to zálohovací zařízení mělo svůj vlastní napájecí zdroj, protože když Vám v serveru shoří zdroj, tak poměrně často vezme ssebou board a disky. Když Vám shoří elektronika všech disků v RAIDu, tak je Vám parita na plotnách jaksi k prdu Ještě lepší je, zálohovat po síti někam kus dál, mimo stojan/místnost/budovu (pro případ požáru) - stačí mít někde k dispozici kus místa na fileserveru. Bavíme se řádově o gigabajtech, to je vcelku legrace.
Pokud se týče CPU (dnes Nehalem vs. Phenom): s procesory AMD nemám mnoho zkušeností, kvůli kompatibilitě mám radši Intel (CPU i čipset) - nicméně než přišel Nehalem, tak AMDčka kralovala v obasti latencí přístupu do RAMky (protože mají on-chip řadič RAM). To je přesně vlastnost, která hraje roli v databázové zátěži (práce s indexy, běh obecných aplikací). V případě FreeBSD bych měl možná maličko strach z kompatibility integrovaného SATA řadiče (v ne-intelském čipsetu) s operačním systémem, ale na 95% je ten strach abstraktní/zbytečný. AMDčkové stroje mívají oproti intelským čipsetům nižší strop sekvenční průchodnosti na disky, ale ve Vašem případě na ten sekvenční strop nenarazíte, protože úzkým hrdlem bude IOps strop disků a dva disky jsou s tím stropem čipsetu i sekvenčně tak nastejno.
Pokud si budete stavět server ze součástek za málo peněz, tak určitě má smysl pořídit si rozumně kvalitní motherboard s AMDčkem (nebo nějaký entry-level Nehalem v rozumném boardu), hodně RAMky a 1-2 Velociraptory + nějakou Barracudu nebo Caviar Green v externím USB rámečku (pokud nemáte někde na LANce spřátelený fileserver).
U externích USB rámečků pozor na dostatečnou ventilaci (nemívají větrák) - buď použijte jednoplotnový disk (třeba aktuální Barracudu 7200.12 až do 500 GB), nebo ten externí USB boxík trochu klempířsky upravte, aby se disk nepřehříval (nebo oboje).
Ohledně RAMky, pokud je na výběr: na shodném taktu má DDR2 nižší latence než DDR3 (resp. si vydělte CL/hodiny a dostanete hodnotu v sekundách). "ECC Registered" paměti na shodném taktu jsou pomalejší než unbuffered. V některých případech latencím pomůže, připojit na relativně pomalý řadič RAM (třeba s podporou DDR2/533) nějaké DIMMy, které mají vysoký jmenovitý takt (třeba DDR2/800) - na nižším taktu běží s kratším "CL". Je to proto, že v obchodní dokumentaci se sice CL udává v jednotkách taktů, ale v SPD EEPROM na DIMMu je ve skutečnosti uložen v nanosekundách - takže si ho BIOS při nižším taktu spočítá na odpovídající nižší počet cyklů. Vlastně z toho plyne, že ta latence v nanosekundách je pro daný modul fixní... je to víceméně vodítko, jak porovnávat latenci modulů o různých jmenovitých taktech. Taky se může stát, že paměť s příliš rychlým jmenovitým taktem nepůjde v "pomalejším" motherbordu použít (i to se stává, těžko říct, jestli je to impedančním nepřizpůsobením, nebo demencí BIOSu). Většina výrobců DIMMů (klasicky třeba Kingston) mívá jednak "obyčejnou" řadu výrobků, druhak "vyladěnou gamesáckou" řadu s vyšším taktem a trochu nižší latencí (třeba Kingston HyperX), a v některých případech jsou v nabídce dále moduly s ještě kratší latencí (Kingston HyperX "LL" nebo "ULL") - bývají dražší a hůře dostupné. Kratší latence se Vám projeví nižším vytížením resp. větším výkonem procesoru - protože řadič paměti vkládá wait staty transparentně a instrukční pipeline procesoru se po dobu čekání na data zablokuje, takže dané jádro nemůže dělat nic jiného (pokud neuvažujete HT).
Pouvažujte o solidní síťové kartě - já bych sáhl po Intelu, ostatní mohou mít jiný názor... ušetří Vám to taky nějakou zátěž CPU. V desktopových boardech, zejména s neintelskými čipsety, se dobré síťovky Intel nebo třeba Broadcom onboard prakticky nevyskytují (spíš nějaký Realtek, Marvell nebo VIA). Čili může Vám pomoci, pokud do PCI nebo PCI-e slotu přidáte síťovku od Intelu, podle mého ani nemusí být echt serverová, snad stačí desktopová (stojí asi čtvrtinu).
Nemusíte ani honit stovky wattů, stačí dobrá čtyřstovka - ale cena bude mezi 30-50 Euro.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
#!/usr/bin/perl
use Net::Ping;
my $ping_target = "192.168.2.8";
my $patience = 6;
my $timeout = 1;
my $num_timeouts = 0;
#my $p = Net::Ping->new();
my $p = Net::Ping->new("icmp",$timeout);
while (1)
{
if ($p->ping($ping_target))
{
#print "okay, reachable \n";
}
else
{
#print "unreachable!\n";
$num_timeouts++;
}
if ($num_timeouts == $patience)
{
print "Going to reset eth0: ";
system("LANG=en_US date");
system("ethtool -r eth0");
$num_timeouts = 0;
sleep(6);
}
else
{
sleep(1);
}
}
Obecné srovnání výkonu databáze na Linuxu vs. FreeBSD, to je tenký led, na který se nebudu pouštět. Ta databáze asi nepojede přímo na holý disk, ale skrz VM+filesystém - a ty se posledních pár let dost bouřlivě vyvíjejí, hlavně na Linuxu... Pokud Vás ten rozdíl opravdu zajímá, možná uděláte nejlíp, když na tom stroji nainstalujete oboje a zkusíte nějaký benchmark Ačkoli podle mých zkušeností se reálná zátěž simuluje dost těžko...
Tiskni
Sdílej:
