Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Bel Shamharoth

Stran: [1]
1
Server / Re:Databáze - 300 GB tabulka
« kdy: 14. 03. 2021, 22:09:39 »
  • MariaDB s InnoDB je na toto naprosto v pohodě, osobně bych použil ji.
  • Docela by mě zajímalo, co znamená "spousta paměti", alespoň 1/2 dat? Jestli míň, tak to může být docela problém.
  • Primární klíče se musí za každou cenu vejít do cache.
  • Nevisí to na storage? Plotna tohle nedá.
  • Pokud je dost paměti, tak si potuňte velikost buffer_poolu, max_dirty_pages (vysoké procento), nastavte si velký undo_log (řekněme alespoň 100GB), vypněte adaptive flushing, innodb_flush_log_at_trx_commit=2 (případně 0), innodb_adaptive_hash_index=OFF
  • Co transakce? Není to co zápis, to commit?
  • Věci jako velká tmp tabulka, ramdisk atp. nechte gynekologovi. To je tady totální plýtvání operační pamětí.

2
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 11. 11. 2020, 11:38:02 »

Tohle by nestačilo?

https://github.com/KizzyCode/timeout_io/blob/master/tests/acceptor.rs
Chápu argumenty typu "tohle by mělo být v základní knihovně", ale to "dávno" je dost závislé na tom, kolik lidí to trápí a kdo to může přidat...

Tohle vypadá, že by i mohlo nějak fungovat, ale je to zase externí věc. Mě jde o to, že tohle se řešilo např. https://github.com/rust-lang/rust/issues/31615 v roce 2016. A jako tohle musí pálit každého, kdo píše síťovou službu. Přeci nemůžete zůstat viset na socketu dokud Vás nesestřelí.

Já nechci hanit rust, mě jen přijde, že sice žije komunita kolem jazyka, ale jazyk samotný už moc ne. Navíc, kdo vlastně za rustem stojí, Mozilla? To taky není moc perspektivní partner (v porovnání třeba s go a Googlem), servo je taky dead.

3
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 10. 11. 2020, 17:31:20 »
S dovolením bych se vrátil k rustu. Docela by mě zajímalo, jestli se ten jazyk vůbec ještě vyvýjí. Mě totiž příjde takový napůl mrtvý.

Proč? Před lety, když jsem ho zkoušel, tak jsem skončil na TcpListeneru, kterému nebylo možné nastavit timeout (a taková služba se prostě musí sestřelovat a tudíž je téměř nepoužitelná). Tenkrát jsem rust odložil jako jazyk ještě ve vývoji. Nic méně dívám se, že i po letech tahle základní funkcionalita pořád chybí. Exsituje sice crate net2, který vypadá, že by to mohl doplnit, ale tohle už mělo být dávno doplněné ve std. knihovně.

Neví někdo, jak je to s vývojem rustu? Tohle totiž moc živě nevypadá.

4
Hardware / Re:Zálohování na pásku - pomalé LTO-2
« kdy: 28. 02. 2017, 18:37:56 »
Kód: [Vybrat]
SCSI 2je v pohodě, na FC ULTRIUM LTO-5 to taky píše SCSI 2 a rychlost je OK (přes 100MB/s).


5
Server / Re:Mysql a ext4 writeback
« kdy: 31. 01. 2017, 20:35:53 »
Řekl bych, že je to docela jedno, ale osobně u ext4, kde mi záleží na datech používám defaultní (a tudíž nejlíp otestované) ordered. Nebo to můžeš přesunout na XFS, které vlastně používá writeback samo od sebe.

Nic méně výkonnostní rozdíl na innodb nebude buď žádný, nebo bude i tak DB nepoužitelná. Disk, hlavně rotační, prostě nesmí být úzké hrdlo.

Pokud máš hodně zápisových transakcí a jsi ochotný jich pár v případě výpadku obětovat, tak si spíš pohraj s innodb_flush_log_at_trx_commit. Plus samozřejmě innodb_buffer_pool_size, innodb_max_dirty_pages_pct, innodb_io_capacity atd.

6
Server / Re:Obnova MySQL databáze je pomalá
« kdy: 05. 11. 2015, 14:33:11 »
SQL příkazy pro vypnutí indexů/kontroly ref. integrity umí do dumpu dávat rovnou mysqldump - již jsem uváděl parametry.

Referenční integritu ano, ale vypnout klíče umí bohužel jen MyISAM, který snad nepoužívají. Resp. ono to tam je a je to ignorované.

7
Server / Re:Obnova MySQL databáze je pomalá
« kdy: 04. 11. 2015, 19:23:26 »
Pokud je to komprimovaný dump, tak 2 hodiny jsou bohužel asi odpovídající. Extended insert je u mysqldumpu default bůh ví jak dlouho, tady problém nebude. S disky taky problém nebývá, ty se většinou flákají. Problém je, pokud to mysql není nastavené totálně blbě, s indexy, ale s tím se toho moc nenadělá. Můžete si dumpnout zvlášť schema, to si upravit odřezáním indexů z create table, pak zvlášť data a nakonec ručně indexy, to by možná mohlo něco urychlit (postgres to tak dělá, pokud vím).

Nic méně pro rozumně rychlou obnovu je lepší raw kopie.

Replikaci u MySQL dostatečně nedůvěřuji a stejně potřebujete raw kopii.

8
Server / Re:Datábaze v ramdisku
« kdy: 03. 03. 2015, 15:00:12 »
Pouze u MySQL se chybejici funkcionalita supluje prostredky operacniho systemu.

Právěže ne. InnoDB si právě dělá všechno samo (mělo by to fachat i s RAW zařízením, ale to jsem nezkoušel) a nepoužívat s InnoDB DirectIO je z 99% nesmysl (tím 1% myslím současné používání jiných storage enginů). To co píšeš platí zejména pro Firebird, do značné míry pro Postgres a pro všechny noSQL co jsem potkal.

Právě InnoDB má toto pořešené dost dobře a je nesmysl ho cpát na ramdisk.

9
Server / Re:Datábaze v ramdisku
« kdy: 02. 03. 2015, 20:15:33 »
Už to tady pár lidí naťuklo, ale nikdo to asi neřekl dostatečně přesvědčivě. Takže pozor:

Vykašli se na ten ramdisk!

Já taky před pár lety podobnou kravinu udělal, protože jsem nerozumněl tomu, jak MySQL funguje. Dnes se tomu směju.

Trocha teorie: MySQL (MariaDB), resp. InnoDB (o MyISAM/Aria 1.x se snad ani nebavíme) všechny operace provádí nad strukturou nazvanou buffer_pool umístěnou v RAM. Disk z pohledu běžícího innodb funguje spíš jako swap v OS kam se hází data až když se nevejdou do paměti (resp. non-dirty data se samozřejmě neukládají, protože tam už jsou, je to analogie trochu volná).

To znamená:

Tu velikost, kterou jsi nastavil ramdisku nastav na buffer_pool v konfiguráku MariaDB, díky tomu budeš mít všechna data v paměti a při čtení se o disk ani neškrne, navíc předejdeš zbytečnému kopírování RAMDisk -> buffer_pool.

Teď zápisy: MariaDB už nemá ten deb... ehm zbytečný limit 4GB na velikost logů. Máš-li místo na disku, nastav velké logy co to jde (typicky bývají ve 2 souborech a nastavuješ velikost jednoho souboru). Tím dosáhnež toho, že každý zápis se provede pouze v RAM + sekvenční zápis do logů (místo okamžitého random zápisu do disku ve tvém RAID1) a jednou za čas (pokud budeš mít velké logy, tak to budou klidně hodiny třebas i den) se část buffer_poolu zapíše na disk (navíc innodb to dělá docela inteligentně). Pokud ti ta rychlost bude ještě pořád málo, dej si logy na jiný disk.

Suma sumárum dostaneš takto vždy lepší výkon než nejlepší možný případ toho RAIDu s ramdiskem + plotna. Data budou vždy konzistentní (vše je v logách), jediný "problém" se kterým musíš počítat je, že pokud to spadne, bude chvíli (pár minut) trvat, než se přehrají logy (to můžeš sledovat v error logu). Ale toto je mnohokrát ověřený scénář, který funguje a na který se můžeš spolehnout. Ehm až teda na pád při běžícím alter table, truncate table atd., ale to je prostě průšvih návrhu MySQL, kterému se prostě nijak nevyhneš ani svým řešením (a zas tak často se to nestává).

10
Server / Re:Postfix a zpoždění na virusfree.cz
« kdy: 16. 10. 2014, 15:14:57 »
Problem je na strane odesilatele - nema korektne nastavene DNS zaznamy, nebude mit nastaveny spravne dopredny a reverzni zaznam v DNS, take SMTP banner tomu musi odpovidat. Diky tomu pak z VOLNY a CENTRUM skoro zmizel spam... overte si sve DNS zaznamy, hlavne jestli mate reverzni zaznam a jestli vas SMTP banner tomuto nazvu odpovida a nebudete mit problem. Hosi z virusfree to maji nastaveno spravne, lec ponekud velmi striktne a proto se pak lidi lini studovat RFC divi.

Pán tam asi pracuje :-) Je to totiž stejná odpověď, jakou člověk dostává z virusfree. Člověk jim desetkrát napíše (a pokaždé ověří), proč odmítají maily, když je vše v pořádku (DNS, SPF, DKIM, množství mailů...) a oni mu 10x napíšou nějakou kravinu, jako např. že nesedí reverzní záznamy. Když se člověk po 11. zeptá jaký reverzní záznam nesedí, protože i z toho centrumáckýho testu má ověřeno, že reverzy jsou skutečně OK. Tak mu odpoví, že je to JEHO starost a že oni mu to říkat nebudou a že mají všechno v pořádku. A nakonec z nich vyleze, že ty maily skutečně v pořádku byly, ale danou doménu mají poznačenou, jako hromadný mail to přes den prakticky nepřijímají.

Virusfree udělali z emailu zcela nespolehlivou službu, podle vzoru: "Když nedojde nic, nedoje ani spam.". Bohužel to jejich klientům asi nevadí a dokud vadit nezačne, tak se to asi nezmění...


11
Sítě / Re:Teredo2Teredo spojení nefunguje
« kdy: 03. 10. 2014, 21:58:04 »
OK, díky.

12
Sítě / Re:Teredo2Teredo spojení nefunguje
« kdy: 03. 10. 2014, 14:54:32 »
To je hezký...

na HE se mi nechtělo registrovat, ale asi mi nic jiného nezbude. Z odpovědi jsem nepochopil, HE potřebuje veřejnou IP u klienta?

Díky.

13
Sítě / Teredo2Teredo spojení nefunguje
« kdy: 03. 10. 2014, 12:34:18 »
Zdravím.

má někdo větší zkušenosti s miredo/teredo tunelem? Jelikož mi poskytovatel neumožňuje mít veřejnou IP, snažil jsem se rozchodit vzdálený přístup přes IPv6 a miredo. Narazil jsem ale na nepříjemný problém a fakt nevím, jestli jde řešit. O co jde:
miredo -> nativní IPv6 je OK.
nativní IPv6 -> miredo je OK.
miredo -> miredo nefunguje.

Problém je v tom, že miredo/teredo je příliž chytré a pokud může klienty propojit bez relaye, snaží se připojit p2p. Jenže tady to zařezává FW s NATem na IPv4 síti a ať se snažím sebevíc, tak se mi to nepodařilo obejít. Jediná možnost je povolit na FW přesměrování portů, aby pakety došly, pak ale musím mít oba FW pod správou.

Neví někdo, jestli se s tímhle dá něco dělat, jde tady nějak udělat NAT traversal?

14
Server / Re:mysql io i po reinstalaci
« kdy: 03. 05. 2014, 07:36:21 »
Nechybí tam náhodou místo na disku? Dál bych zkusil dd přečíst celý disk a sledovat tok.

Stran: [1]