Byla vydána zářijová aktualizace aneb nová verze 1.83 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.83 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Oficiálně byl vydán Android 14. Detaily na blogu a stránkách věnovaných vývojářům.
Google na akci Made by Google '23 (YouTube) představil novinky v kolekci produktů Pixel: hodinky Pixel Watch 2 a telefony Pixel 8 a Pixel 8 Pro s čipem Tensor G3, Androidem 14 a 7letou softwarovou podporu.
Byla vydána nová verze 9.5 sady aplikací pro SSH komunikaci OpenSSH. Nově ve výchozím stavu ssh-keygen generuje Ed25519 klíče. Do ssh byla přidána možnost obfuskace časováním stisknutí kláves (keystroke timing obfuscation).
Konference OpenAlt 2023 proběhne o víkendu 11. a 12. listopadu v Brně. Přihlásit přednášky lze do neděle 8. října 23:59.
V X.Org v libX11 do 1.8.7 a libXpm do 3.5.17 bylo nalezeno a v upstreamu opraveno 5 bezpečnostních chyb (CVE-2023-43785, CVE-2023-43786, CVE-2023-43787, CVE-2023-43788 a CVE-2023-43789). Dvě nejstarší jsou s námi 35 let. Obsaženy byly již v X11R2 vydaném v únoru 1988.
Byly publikovány informace o bezpečnostní chybě Looney Tunables aneb CVE-2023-4911 v glibc ld.so. Útočník ji může využít k lokální eskalaci práv. Vyzkoušeno na výchozích instalacích linuxových distribucí Fedora 37 a 38, Ubuntu 22.04 a 23.04 a Debian 12 a 13. Chyba byla do glibc zavlečena v dubnu 2021. Detaily v txt.
Na Kickstarteru byla spuštěna crowdfundingová kampaň na podporu telefonu Murena 2 s /e/OS. Telefon má 2 hardwarové přepínače. Prvním lze jednoduše vypnout kamery a mikrofony. Druhým se lze odpojit od sítí.
Společnost Qualcomm publikovala říjnový bezpečnostní bulletin. V úvodu informuje, že bezpečnostní chyby CVE-2023-33106, CVE-2023-33107, CVE-2022-22071 a CVE-2023-33063 jsou cíleně využívány útočníky. O CVE-2022-22071 se píše už v loňském květnovém bulletinu. Detaily o zbylých chybách jsou k dispozici OEM partnerům. Veřejně budou k dispozici až s vydáním prosincového bulletinu.
Byla vydána nová verze 5.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 12.5.6. Tor na verzi 0.4.8.6.
atlas ~ # free total used free shared buffers cached Mem: 2042540 2000016 42524 0 1704044 14188 -/+ buffers/cache: 281784 1760756 Swap: 2987516 760 2986756Testovacie dáta sú tvorené asi 9 miliónmi súborov, rozdelených po adresároch do dvoch úrovní: dir1/dir2/files, pričom dir1 je číslo od 1 do 18, dir2 číslo od 1 do 256, a v každom z nich je asi 2000 files. T.j. na prvej úrovni je 18 adresárov, na druhej 256 adresárov (v každom z tých 18-tich) a na tretej 2000 súborov (v každom z tých 256). Testovacie dáta majú spolu 3 TB (obsadenie filesystému na 50%). Skúšal som to na ext2 a ext3, chystám sa vyskúšať aj ďalšie filesystémy. Hardvér je: HP ProLiant DL160G6, 1x CPU E5506, 1x 2GB RAM, 4x HP 2TB 3G SATA 7.2K 3.5" Je mi jasné, že bude potrebné dokúpiť ďalšiu RAM, otázka ale je, že koľko? V ideálnom svete čo najviac, ale v reáli keď dáme všetky peniaze na pamäť, môžu nám potom chýbať inde. Preto sa na Vás obraciam, či niekto nemá skúsenosť s takto obludnými oddielmi a rozsiahlou populáciou súborov. Neexistuje nejaký vzorec, podľa ktorého by sa dalo vypočítať, že pri počte súborov X bude potrebná RAM najmenej Y ? Budem ale rád aj za iné návrhy, či pripomienky. Vopred vďaka. AraxoN
Řešení dotazu:
/proc/PID/
.
Skontroluj súbor limits,status. V prípade, že spúšťaš úlohu pod ID väčším ako 0, tak sú tam určité limity.
Hlavne treba sledovať výpisi čo dáva program a sledovať systempvé logovacie súbory.
Potom sa možnu bude dať určiť ďalší postup.
#!/bin/sh SRC=/root/test_data DST=/mnt/data mkdir $DST/files for i in `seq 1 18` ; do mkdir $DST/files/$i for j in `seq 0 255` ; do echo $i/$j mkdir $DST/files/$i/$j cp $SRC/* $DST/files/$i/$j done done
cp $SRC/* $DST/files/$i/$jcp $SRC/* $DST/files/$i/$j
mkdir $DST/files/$i
a mkdir $DST/files/$i/$j
a mkdir $DST/files/$i/$j
time
.atime
a noatime
je iba niekoľko percent (samozrejme v prospech noatime
).
iotop
? Není ztráta rychlosti na žurnálu?
Zkusil jsem si totéž v menším rozsahu, mám podobný i když podstatně méně výkonný server. (4x1,5TB v raid5, nad tím lvm, nad tím ext4, a poháněné úsporným AMD Zacate s 4GB paměti). Spuštění Vašeho upraveného skriptu dává cca 40-70MB/s zápisu. Oddíl na LVM je celkem zaplněn (přes 2,5 TB dat a cca 500GB volný, proto jsem zapisoval jen 100GB). Přímý sekvenční zápis 1GB souboru
dd if=/dev/zero of=file1G.tmp bs=1M count=1024mi dává rychlosti cca 130-135 MB/s
$free total used free shared buffers cached Mem: 3607968 3505856 102112 0 173252 3100984 -/+ buffers/cache: 231620 3376348 Swap: 0 0 0veškeré operace jsem dělal pod běžným uživatelem.
top
je iotop
setříděné podle procesu, které mají největší io. Takže zajímavé jsou ty nahoře
V ext4 (a tuším i v ext3) je journal proces jbd2
.
atop
, který také ukazuje okamžité rychlosti a zátěže jednotlivých fyzických disků pole, rychlost a zátěž raidu i oddílů.
dstat
- cez -D sa dajú vypísať jednotlivé blokové zariadenia (t.j. cez dstat -D md4,sda,sdb,sdc,sdd
vidím všetko podstatné). Atop skúsim.
RAID5 znamena pro server nejen pocitani parity, ale i 4x duplikovane IO operace, kazdy zapis i cteni(o jednu IO mene) na disk vyzaduje zapsani dat na vsechny disky. Toho te zbavi jen HW raid.Jakto, že mě toho zbaví HW RAID. Samozřejmě nezbaví. Protože i on musí 4x zapsat data na disk, i on musí počkat na disky, až se provedou seeky. Při pohledu na datové rozhraní disku není v přenosu rozdíl. Pokud mám kvalitně provedenou základní desku, a tím myslím, že všechny disky mohou jet současně přenosy do paměti v plné rychlosti, které jsou schopny, není naprosto žádný důvod, proč by SW RAID neměl mít stejný výkon jako HW RAID. Jasně pokud je deska jednoduchá a datový proud na jednom SATA vyblokuje datové proudy na jiném SATA, tak je to na RAID nepoužitelné. A právě v jednoduchosti desky může být zrada.
ps. jaky si myslis ze je duvod pro kupovani drahych HW raidu i dnes v dobe 8 jadrovych CPU, kdy procesor na beznem serveru ma zatez v jednotkach procent.První důvod je rozdělení výkonu. Pro velké raidy visící třeba na Fibre Channel má smysl. A druhý důvod je marketingová politika výrobců, jejich lenost (že nechtějí dělat jinak zpracované zařízení než na jaké jsou zvyklí) a hloupost a lenost kupců (raději dáme dvakrát tolik a bude to jednoduše fungovat než abychom měli práci se seřízením a nastavením). Je to podobné, jak někdy koncem 80 let se pořád prodávaly minipočítače Digital Equipment VAX xxx. Také jsem slyšel spoustu argumentů, že to je to pravé, když jsem vysvětloval, že pracovní stanice třeba od SUN nebo Silicon Graphics udělá to samé za 1/5 ceny.
Tiskni
Sdílej: