Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
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:
