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 [2]
16
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.

17
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.

18
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á).

19
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í...


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

21
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.

22
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?

23
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 [2]