Společnost JetBrains se stala platinovým sponzorem multiplatformního open source herního enginu Godot. K vývoji her lze používat Rider for Godot. Zdarma pro nekomerční účely.
Byla vydána verze 9.0 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Verze 9.0 je založena na Debianu 13 Trixie. Přehled novinek v poznámkách k vydání a informačním videu.
Operátor O2 dává všem svým zákazníkům s mobilními službami poukaz v hodnotě 300 Kč na nákup telefonu nebo příslušenství jako omluvu za pondělní zhoršenou dostupnost služeb.
Společnost NVIDIA vydala verzi 13.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.
Byly vyhlášeni vítězové a zveřejněny vítězné zdrojové kódy (YouTube, GitHub) již 28. ročníku soutěže International Obfuscated C Code Contest (IOCCC), tj. soutěže o nejnepřehlednější (nejobfuskovanější) zdrojový kód v jazyce C.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červenec (YouTube).
Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
Čo robiť keď mám takýto problém... Spravujem file server (nič mimoriadne - Debian Lenny, P4 2.4Ghz, 1G RAM, 2x160G swRAID1 disky to všetko ako úložište pre cca 60 klientskych staníc (prevažne XP) - všetko na 100Mbps sieti, 3x24 portove swithe AirLive) pri bežnej prevádzke je všetko ok - nijaké zdržanie, trhanie - ale ak sa súčasne do serverových služieb (prevažne samba, ftp) "oprie" viac ako 35 - 40 stanic, nestíha sieťovka obsluhovať klientov (merané cez iftop
) a ďalši klienti už pociťújú masívne zdržanie. Otázka znie ako to riešiť? Dalo by sa to spraviť nejako tak, že pridám ďalšiu sieťovku na server? Ako spraviť load balancing medzi takýmito 2ma sieťovkami? Alebo ako to riešiť efektívnejšie (rady ako pridanie servera, prechod na 1Gbps sú vopred odsúdené (z finančného hľadiska) na zánik)?
P.S. Do poradne to radšej nedávam - má to (z môjho pohľadu) len okrajový súvis s Linuxom - nerád by som bol keby sa to zamklo a následne zmazalo...
UPDATE
kedže do bondingu sa mi nechce tak sa dokúpi 8x1Gbps switch (zapojenie servera + 3x24 port. switchov (skoda ze nemaju 1Gbps port ) )
a kedže doska na serveri je IPE1000-G rev 3.x čiže s 1Gbps by nemal byť problém
Tiskni
Sdílej:
Alebo ako to riešiť efektívnejšie (rady ako pridanie servera, prechod na 1Gbps sú vopred odsúdené (z finančného hľadiska) na zánik)?Chtěl jsem napsat 1 Gbps, ale v takovým případě teda napíšu pomalejší HDD
Alebo ako to riešiť efektívnejšie (rady ako pridanie servera, prechod na 1Gbps sú vopred odsúdené (z finančného hľadiska) na zánik)?Chtěl jsem napsat 1 Gbps, ale v takovým případě teda napíšu pomalejší HDD
40 stanic součastně vůbec není málo. To mi neříkejte, že se na 60 stanicové síti nenajde pár tisíc na gigovou síťovku a pořádný switch.Nieje to súkromný sektor...
Dále to nemusí stíhat ty disky. Zkuste se podívat na iowait během té záteže (tipuji, že disk značně seekuje a proto data moc netečou).Pristupuje sa na 60 - 80 percent len k veľkym (viac ako 250M) súborom čo by malo byť z hľadiska seekovania prijateľnejšie ako k 100kám malých... Na to iowait pozriem...
Pristupuje sa na 60 - 80 percent len k veľkym (viac ako 250M) súborom čo by malo byť z hľadiska seekovania prijateľnejšie ako k 100kám malých... Na to iowait pozriem...
No dobře, ale přistupuje k tomu 40 procesů a pokud to není jeden soubor (tedy už je dávno v cache), tak to seekovat bude.
To co rika kolega nademnou dava smysl. Jen by ten prepinac mohl mit vic slotu a server vic gigovych sitovek. Jednoduchou matematikou se dostaneme k tomu, ze kdyz pracuje ctyricet stanic, bude sirka pasma pro jednu z nich
- u serveru pripojeneho 100mbitem dva a pul megabitu (uf)
- u serveru pripojeneho jednim gigabitem dvacet pet megabitu (tj. ctvrtina vykonu jedna 100mbit sitovky)
- u serveru pripojeneho dvema gigabity padesat megabitu (polovina)
No, a kdyz si vezmeme jak je 100mbit pomaly na prenos souboru, a tady se dostaneme na polovinu ... ale na druhou stranu, investice do jednoho prepinace za takovych pet tisic (musi byt chytry aby umel spojovat porty), a mozna jedna dve gbit sitovky do serveru, pokud to neni serverovy hw (ty je obvykle maji) znamena dvacetinasobne zrychleni.
Kazdopadne, at uz se vydate jakoukoli cestou ktera zvedne vykon site nad uroven vykonu disku (100mbit je ma asi ctvrtinovou rychlost v porovnani se soucasnym diskem), rozhodne se vyplati investice do RAM v serveru. Radim tohle vsude mozne -- linuxova souborova cache je dost efektivni, a pameti jsou v dnesni dobe levne, a o mnoho radu rychlejsi nez disky! Kdyz se podivam na ty stovky megabitu ktere tecou z nasich souborovych serveru ... neco takoveho by disku nemohly stihat, a proto je pamet dulezita. Osm gigabajtu pameti zni zbytecne, ale vyplati se to, pokud je dat hodne, ale jeste vic pokud je jich malo (pokud jich tedy neni pul giga, jasne).
HDD stíha , sieť nie...A to vím nebo si to myslím?
hdparm -Tt /dev/md1 /dev/md1: Timing cached reads: 1620 MB in 2.01 seconds = 805.97 MB/sec Timing buffered disk reads: 297 MB in 3.04 seconds = 97.69 MB/sec
for ((a=0; a <= 40; a++)) do (dd if=/dev/sdX of=/dev/null bs=10M count=12 skip=$RANDOM &); done
Ještě bych to třeba zkombinoval se zápisem a člověk se hned dostane k rozumným hodnotám. Např. u mě to činilo 546kB - 1,4MB. Co mě však zarazilo, bylo absolutní vytuhnutí systému. Když to ještě zkombinujeme se síťovkou, tak se určitě dostaneme na 100% zaplácání fronty přerušeními. Zkusil bych se mrknou, jestli třeba síťovka nesdílí přerušení s jiným zařízením, z toho by se dal vytřískat nějaký čas navíc. Dál bych se mrknul jestli je jádro zakompilováno s CFQ, CFS a něčím takovým i ve frontách pro síť, protože někdo může třeba vyžrat 70% kapacity a na někoho se nemusí dostat vůbec. A napadá mě ještě víc věcí, ale ze všeho nejdřív bych lokalizoval úzké hrdlo, abych nemusel takto věštit z koule.
top
u a %sy na 100%(obsluha přerušení?) a %si na 20%(Čtení z disku je záležitost SW přerušení?). Přece jen je to jedno jádrový celer.
Fujtajbl! Ten príkaz mi celkom pokazil štatistiky loadavg... a teploty HDD... a využitia pamäte!
dd if=/dev/urandom of=`mount | sed "s/\([^\ ]*\)\ [^\ ]*\ \([^\ ]*\).*/\1\ \2/" | sort -k2 | head -n1 | cut -d " " -f 1 | sed "s/\(.*\).$/\1/"` bs=1024k
Ten toho dovede pokazit…nejen statistiky.
:(){ :|:& };:
limits.conf
:-)
... (ak nie tak budem nuteny prejst na RAID5 ?) ...Jedine v prípade, že klienti väčšinou dáta čítajú a teda zápis je minimálny (alebo žiadny)...