Příspěvky

91

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 21. 03. 2021, 11:13:23 »

Pokud onen test dělám na zfs výsledek je tohle:

Kód: [Vybrat]

fio --name=randrw --rw=randrw --direct=1 --ioengine=libaio --bs=16k --numjobs=1 --rwmixread=80 --size=10G --runtime=300 --group_reporting
randrw: (g=0): rw=randrw, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=libaio, iodepth=1
fio-3.12
Starting 1 process
randrw: Laying out IO file (1 file / 10240MiB)
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT
randrw: No I/O performed by libaio, perhaps try --debug=io option for details?
fio: pid=14301, err=22/file:filesetup.c:701, func=open(randrw.0.0), error=Invalid argument


Run status group 0 (all jobs):

Jinak nastavení zfs mám:

Kód: [Vybrat]

zfs get all /ovps/clondbn3
NAME           PROPERTY              VALUE                  SOURCE
ovps/clondbn3  type                  filesystem             -
ovps/clondbn3  creation              Tue Jan  5 11:00 2021  -
ovps/clondbn3  used                  177G                   -
ovps/clondbn3  available             170G                   -
ovps/clondbn3  referenced            177G                   -
ovps/clondbn3  compressratio         1.00x                  -
ovps/clondbn3  mounted               yes                    -
ovps/clondbn3  quota                 none                   default
ovps/clondbn3  reservation           none                   default
ovps/clondbn3  recordsize            4K                     local
ovps/clondbn3  mountpoint            /ovps/clondbn3         default
ovps/clondbn3  sharenfs              off                    default
ovps/clondbn3  checksum              on                     default
ovps/clondbn3  compression           off                    default
ovps/clondbn3  atime                 off                    inherited from ovps
ovps/clondbn3  devices               on                     default
ovps/clondbn3  exec                  on                     default
ovps/clondbn3  setuid                on                     default
ovps/clondbn3  readonly              off                    default
ovps/clondbn3  zoned                 off                    default
ovps/clondbn3  snapdir               hidden                 default
ovps/clondbn3  aclinherit            restricted             default
ovps/clondbn3  createtxg             544563                 -
ovps/clondbn3  canmount              on                     default
ovps/clondbn3  xattr                 on                     default
ovps/clondbn3  copies                1                      default
ovps/clondbn3  version               5                      -
ovps/clondbn3  utf8only              off                    -
ovps/clondbn3  normalization         none                   -
ovps/clondbn3  casesensitivity       sensitive              -
ovps/clondbn3  vscan                 off                    default
ovps/clondbn3  nbmand                off                    default
ovps/clondbn3  sharesmb              off                    default
ovps/clondbn3  refquota              none                   default
ovps/clondbn3  refreservation        none                   default
ovps/clondbn3  guid                  15047711894469677623   -
ovps/clondbn3  primarycache          all                    default
ovps/clondbn3  secondarycache        all                    default
ovps/clondbn3  usedbysnapshots       128K                   -
ovps/clondbn3  usedbydataset         177G                   -
ovps/clondbn3  usedbychildren        0B                     -
ovps/clondbn3  usedbyrefreservation  0B                     -
ovps/clondbn3  logbias               latency                default
ovps/clondbn3  dedup                 off                    default
ovps/clondbn3  mlslabel              none                   default
ovps/clondbn3  sync                  standard               default
ovps/clondbn3  dnodesize             legacy                 default
ovps/clondbn3  refcompressratio      1.00x                  -
ovps/clondbn3  written               10.2G                  -
ovps/clondbn3  logicalused           177G                   -
ovps/clondbn3  logicalreferenced     177G                   -
ovps/clondbn3  volmode               default                default
ovps/clondbn3  filesystem_limit      none                   default
ovps/clondbn3  snapshot_limit        none                   default
ovps/clondbn3  filesystem_count      none                   default
ovps/clondbn3  snapshot_count        none                   default
ovps/clondbn3  snapdev               hidden                 default
ovps/clondbn3  acltype               off                    default
ovps/clondbn3  context               none                   default
ovps/clondbn3  fscontext             none                   default
ovps/clondbn3  defcontext            none                   default
ovps/clondbn3  rootcontext           none                   default
ovps/clondbn3  relatime              off                    default
ovps/clondbn3  redundant_metadata    all                    default
ovps/clondbn3  overlay               off                    default

92

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 21. 03. 2021, 00:03:17 »

ještě malý tip, v případě mysql a innodb je vždy nejrychlejší nejprve debugovat přímo O_DIRECT zápis s 16KB, je dobré vyzkoušet více kernelů, zejména po 4.8 byly nějaké regrese na ssd/nvme. Výkonnost mysql to pak reflektuje většinou velice dobře, výjimkou je ext4, který je dost šíleny pro databáze a měření. Pokud máš tak velké rozdíly proti ext4, máš zfs nevhodně nastavený, projdi nastavení znovu, najdi mikrobench, který ti dovolí rychleji zkoušet různé varianty

Jak pomocí microbench debugovat O_DIRECT u zfs jsem nepochopil ani nikde nenašel.  Ale myšlenka že testovat raději přímo výkon disku než výkon databáze je dobrá, protože je to podstatně snandnější a rychlejší.

Testoval jsem pomocí příkazu pro testování náhodného zápisu bloků 4KB:  (způsob jak testovat jsem převzal z blogu zde https://martin.heiland.io/2018/02/23/zfs-tuning/)

Kód: [Vybrat]

fio --filename=test --sync=1 --rw=randwrite --bs=4k --numjobs=1 --iodepth=4 --group_reporting --name=test --filesize=10G --runtime=300 && rm test

Nevím proč, ale největší výkon naměří na obyčejném disku (ne SSD) se ZFS, když mám recordsize=4K. A to.
write: IOPS=1137, BW=4550KiB/s (4659kB/s)(1333MiB/300003msec); 0 zone resets
Je to několikanásobně lepší výsledek než při všem ostatním.
To stejné při defaultním recordsize=128K
write: IOPS=280, BW=1121KiB/s (1148kB/s)(328MiB/300001msec); 0 zone resets
Pokud to stejné pustím na stejném disku ale s ext4, tak dostanu
write: IOPS=277, BW=1109KiB/s (1135kB/s)(325MiB/300088msec); 0 zone resets

Pokud to stjené pustím na SSD disku na zfs s recordsize=4K tak je výsledek pět cca stejný
write: IOPS=288, BW=1154KiB/s (1182kB/s)(338MiB/300006msec); 0 zone resets

Pokud ale nastavím defalutních recordsize=128K pak se ZFS s SSD diskem zmůže jen na cca poloviční výkon
write: IOPS=127, BW=510KiB/s (522kB/s)(149MiB/300001msec); 0 zone resets

Bohužel zkusit SSD disk bez s ext4 nemohu.

Testoval jsem ale svůj nový domácí SSD disk na ext4 nvme
write: IOPS=550, BW=2200KiB/s (2253kB/s)(645MiB/300001msec); 0 zone resets

Z toho vůbec nejsem chytrý. Vypadá to jako by pro zápis malých bloků nebyly SSD vůbec nějak výrazně rychlejší?
Jak si vysvětlit tu rychlost ZFS s běžným diskem a 4KB recordsize?

93

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 19. 03. 2021, 17:47:06 »

Já jen kroutím hlavou nad tím, že někdo raději koupí dražší hardware jen kvůli tomu, aby měl potenciálně stejný výkon na ZFS jako předtím na ext4. Kdyby bylo složité MySQL zálohovat tak neřeknu, ale tohle mi připadá jako strkání hranolu do kulatého otvoru.

No těch serverů máme hodně. A hlavní databáze musí jet 24/7 bez výpadků. Díky snapshotům je stěhování podstatně jednodušší než dělat z repliky hlavní stroj. Je to prostě příliš složité než aby se neukázal nějaký zádrhel. Chci hlavně jednotný způsob stěhování pro všechny virtuály.
A také se mi nechce věřit že by ten rozdíl byl až takový. S novým strojem budu moci udělat nové testy a hledat proč je rozdíl tak velký.

94

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 18. 03. 2021, 10:48:45 »

Dobrý den,

provozujeme SQL databáze většinou nad Proxmox ( KVM ) a využíváme ZFS. 

S výkonem MySQL jsme vcelku laborovali. Máme hodně malých transakcí což generuje malý datový tok, ale velké množství zápisů na disk tedy fsync.

V našem případě dramaticky pomohla změna nastavení
 - pro zápis změnit fsync  viz https://www.percona.com/blog/2018/02/08/fsync-performance-storage-devices/
 - Pro čtení jsme alokovali dostatek paměti tedy čtení nešlo skoro vůbec z disku.

Nakonec to stejně nebylo dostatečně výkonné a tak jsme přešli pro část dat k REDISu potažmo keydb.dev
a aplikačně pak v časových intervalech propisujeme do DB.

Testovali jsme jak levné tak dražší SSD disky.
Problémem u SATA/SAS byl většinou výkonnost RAID řadiče.

Nakonec jsme zvolili variantu NVMe s pro jistotu větším TBW jako je
https://www.alza.cz/corsair-force-series-mp510b-960gb-d5863484.htm

A aby jich šlo dát do standardního serveru více tak PCIe switch jako kupříkladu :
https://www.supermicro.com/en/products/accessories/addon/AOC-SLG3-2M2.php
https://www.supermicro.com/en/products/accessories/addon/AOC-SHG3-4M2P.php

Je to dva roky a mezi tím se HW raketově posunul.

Vřele mohu doporučit Davida Karbana. https://freelancing.eu/davidkarban/
Byl jsem u něj na školení a MySQL a následně nám pomáhal s laděním výkonu v kombinací s bezpečností dat.

V.

Díky za info.  Z odkazují je zřejmé, že rozdíl mezi běžným diskem a nejlevnější SSD sata diskem je podobně velký jako mezi SSD sata diskem a  SSD NVMe. Jak v rychlosti odezvy tak v množství dat za vteřinu. Normálnímu desktopu nebo aplikaci je to téměř jedno, ale v případě databáze to opět může být několikanásobné zrychlení. Tedy v případě náročnější databáze s větším počtem zápisů (to větší RAM neurychlí) to chce opravdu investovat do SSD NVMe

95

Sítě / Re:VoIP nasazení v menší firmě

« kdy: 18. 03. 2021, 08:56:30 »

Já ještě přidám odkaz, který může pomoci jestli si pořídit vlastní ústřednu, nebo využít zdarma virtuální u Odorik.cz
http://www.odorik.cz/w/vyhody_a_nevyhody_vlastni_pobockove_ustredny_asterisk

96

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 17. 03. 2021, 09:13:21 »

Ja bych se na ZFS u databaze vybodnul. Da se to vytunit ale lepsi nez default ext4 to asi nebude.

https://www.percona.com/blog/2018/02/16/why-zfs-affects-mysql-performance/

Zajímavý článek. Nechápu ale proč výkon pro median je nižší než 95 percentil a to jak  u ext4 tak u zfs. Median - update u zfs  má třetinový výkon oproti ext4.
Také nerozumím tomu,  proč dotyčný neuvádí jaký má nastavený recordsize, když ten má zásadní význam pro rychlost databází se zfs. Z popisků grafů na https://github.com/dotmanila/zfs-mysql/tree/master/base-results/zfs to vypadá, že nechal defaultních 128K. Kdyby nastavil  32K nebo menší, mohl mít zjevně výkon dvojnásobný. Taky to vypadá, že měl špatně nastavený logbias=throughput . Tedy jeho špatné výsledky je snad možné vysvětli neoptimálním nastavením. Zato moje špatné výsledky si vysvětlit neumím.  Očekával bych že bude mít zfs třeba o 20% nižší výkon, ale ne že bude několikanásobně pomalejší.

97

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 17. 03. 2021, 09:05:10 »

Co je to za SSD?

Jsou to běžné nejlevnější Kingstone ssd disky v raid 0.  Dříve s nejlevnějšími kingstone nebyly žádné problémy.

pool: ovps
state: ONLINE
scan: scrub repaired 0B in 0h20m with 0 errors on Sun Mar 14 00:44:25 2021
config:

NAME                                            STATE     READ WRITE CKSUM
ovps                                            ONLINE       0     0     0
mirror-0                                      ONLINE       0     0     0
ata-KINGSTON_SA400S37480G_50026B77839D2E97  ONLINE       0     0     0
ata-KINGSTON_SA400S37480G_50026B778397A84B  ONLINE       0     0     0

98

Server / Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 16. 03. 2021, 17:02:52 »

Přecházíme nyní z OpenVZ ext4 na lxc ZFS. Výhody ZFS jsou zřejmé jako snapshoty a tím snadná záloha a klonování.
Ale nyní jsem narazil i na podstatnou nevýhodu a to podstatně nižší výkon.

Jedná se o databázovou aplikaci, která snímá diagnostická data a zapisuje je do databáze.  Je tam tedy velké množstvím inzertů a podobně velké množství updatů, kdy se nasbíraná data vyhodnocují. Po přesunu této aplikace na lxc/ZFS co používá SSD byl výkon oproti starému stroji s rotačním diskem cca poloviční. Co mne ale zaráží je, že jiné kontejnery začaly bezdůvodně ztrácely rtp pakety.
Očekával jsem tak cca čtyřnásobné zvýšení výkonu (kvůli použití SSD) a místo toho se rychlost snížila.

U Openvz se v podstatě nikdy nestávalo, že by přetížení jednoho kontejneru vyvolávalo podstatné problémy v jiném, lxc je o tolik horší? Zkoušeli jsme to stejné ještě na jiném stroji, abychom vyloučili chybu hardwaru, ale výsledek byl velmi obdobný. Dále jsme omezili paměť pro ZFS aby jsme se s jistotou vyhnuli možnému swapování.  Zkoušeli jsme též použít jak inodb tak myISAM. MyISAM je pro nás o něco málo výkonnější, ale žádný podstatný rozdíl.  Jediné co mělo výrazný vliv, je snížení parametru recordsize na 4K.  Např. viz návod https://blog.programster.org/zfs-record-size . Tím se dalo docílit podobné rychlosti jako na starém počítači s rotačními disky.  Stále mi ale nejde do hlavy, jak je možné, že se při využití SSD disků nedostavilo žádné zrychlení. Nečekal jsem že bude ZFS rychlejší, ale rozdíl jsme čekal podstatně menší. Máte někdo s tím zkušenost? Takto si připadám, že co se rychlosti a spolehlivosti týče je to krok zpět. Samozřejmě ZFS může být lepší co se týče integrity dat, ale pokud by to mělo znamenat takto výrazné snížení rychlosti, je otázka, jestli to stojí za to. A pokud je to jen analýza ne úplně důležitých dat, je lepší se ZFS úplně vyhnout?

Máte s tím někdo zkušenost?

99

Sítě / Re:VoIP nasazení v menší firmě

« kdy: 15. 03. 2021, 11:32:26 »

Pro malou firmu, která má provolávku menší než desítky tisíc, se VoIP moc nevyplácí. Co ušetříte na hovorech, to třikrát přeplatíte na správě a problémech. VoIP se musí udržovat pravidelně, právě kvůli bezpečnostním chybám a tomu, že každá chyba může stát velké peníze.

Pokud máte zastropovanou maximální provolávku (bez toho se nepřipojujte), můžete přijít maximálně jen o několikaměsíční provolávku. Tedy u menší firmy jsou potencionální škody spíše ve stokorunách maximálně tisícikorunách.
Pokud si navíc povolíte u operátora jen hovory do zemí kam voláte i kdyby vás někdo hacknul, nejspíš se mu nepodaří vše provolat. Útočník chce volat jen na drahá čísla, z kterých dostává provizi.
Nemluvě o tom, že pokud nebudete nic vystavovat na veřejné ip adrese, pravděpodobnost bezpečnostního incidentu je hodně malá. Řekněme menší než 1:10000 za rok. (vycházím s reálných dat jednoho VoIP operátora)  Tedy je to méně pravděpodobné a navíc méně závažné, než že vás na přechodu v příštím roce srazí auto.
Hlavní důvod proč mít VoIP není o tom ušetřit za volání, ale nabízí to některé věci, které na mobilu nejdou, nebo nejsou dost nepohodlné.
Např. hlasové menu, přepojování hovorů, možnosti paralelního vyzvánění více lidem na více různých místech, kteří se tak mohou lépe střídat, okamžitý přehled o hovorech - kdo jak dobře pracuje, centrální nahrávání hovorů (třeba kvůli vlastnímu zdokonalování se - majitel si může poslechnout, jestli jeho zaměstnanci občas neříkají zákazníkům nesmysly) a další věci. Je možné to integrovat do firemního informačního systému, aby v době kdy volá zákazník už jste viděli např. jeho kartu nebo objednávku.
Naproti tomu řešit všechno přes mobil snadno může vést k tomu, že ten mobil nikdo nebude zvedat, protože je přetížený a dotyčný začne být kvůli neustálému vyrušování neefektivní....  Jde také o špatnou zastupitelnost jednotlivých lidí, když si mobil vezmou s sebou na dovolenou a podobně.

Co se týče nákladů na údržbu. Ano mohou být velké, pokud to vezmete za špatný konec. Ale mohou se též blížit nule i pokud započítáte svůj vlastní čas.  Pokud se to celé dobře rozmyslí, obvykle jsou veškeré náklady jen pořízení a nastavení VoIP telefonů, nebo programu Microsip. Další provozní náklady se blíží nule.

Samotné volání vyjde podobně jak z  mobilu s výjimkou volání do zahraničí, kde je často mnohonásobně levnější.

100

Sítě / Re:VoIP nasazení v menší firmě

« kdy: 13. 03. 2021, 11:35:53 »

Zatím se jako nebezpečné ukazuje jen to, když si dá někdo VoIP telefon na veřejnou adresu, nebo na něj forwarduje porty z veřejné adresy. Bezpečné přihlašovací heslo na telefon nemusí nutně pomoci. Bývá tam druhý skrytý uživatel "user" (kromě typického admin), nebo může být web děravý.
Nebezpečné  může být mít vlastní ústřednu na veřejné adrese, útočníkům také někdy stačí web ústředny dostupný z internetu. Útočníci zatím vždy postupují tak, že skenují internet a hledají potencionální kořist.
Vždy je třeba omezit maximální provolávku, tak aby maximální možná škoda nemohla být více je několikaměsíční útrata za volání. Pokud nevoláte do celého světa, zařiďte si omezení volání do zahraničí tam kam nevoláte. Útočník pak nebude schopen volat na čísla z kterých dostává provizi.
I virtuální ústředna může být úplně zdarma, třeba na Odorik.cz. Výhoda je, že lze snadněji zapojit lidi z různých lokalit i bez VPN a je s tím méně starostí.
Co se týče PoE, tak jde hlavně o to, že pod stolem nezavazí adaptér navíc. Jde  o to jestli jej máte kam dát. Jestli to stojí za ten příplatek si každý musí zhodnotit sám.

101

Hardware / Re:Vývojářský počítač: notebook vs. stolní PC

« kdy: 12. 02. 2021, 11:24:37 »

Já mám stolní počítač a k němu velký 4K monitor + jeden běžný.

Tohle se dá zase řešit dokinou. Mám k NTB přes dokinu připojeny tři 4k monitory. Nicméně pro generační obměnu plánuju stolní, resp. podstolní PC. Moderní NTB to výkonově zvládnou bez problémů, 24-32GB RAM není problém, NVMe SSD taky, ale problém s notebookem je fungování v zátěži, byť kvalitní, tak v zátěži je prostě slyšet a čím delší je zátěž, tím je to protivnější, s nějakým 120mm větrákem ve stolním PC točícím pár set až lehce přes tisíc otáček se to nedá srovnávat.

Také jde o cenu. Počítač co mi v pohodě zvládne 4K pořídím za cca 10 tisíc. (stačí mi integrovaná grafická karta - hry nehraju) Notebook stejného výkonu může být několikanásobně dražší.
Ale pokud mám notebook vyloženě na cesty a do postele. Mohu volit výrazně lehčí a levnější typ. Např. již použitý notebook třeba za 8 tisíc. Vše mám uloženo a vyvíjím přímo na serverech (nebo se serverem může snadno synchronizovat), tedy přecházení ze stolního počítače na notebook není problém.
Dražší notebook nemusí být dobrý nápad třeba i proto, že ho snadno mohou ničit děti. Malé děti mohou vytrhnout třeba klávesu, nebo se na něm procházet. U stolního počítače když si zalepím tlačítko na vypnutí a reset černou pískou tak nic nehrozí, klávesnice je levná.  Nemluvě o tom že vždy trochu hrozí ukradnutí, ztráta, nebo že si jej zničím i sám, tedy raději si na dovolenou vezmu levnější notebook než dělo.

102

Hardware / Re:Vývojářský počítač: notebook vs. stolní PC

« kdy: 11. 02. 2021, 13:06:21 »

Já mám stolní počítač a k němu velký 4K monitor + jeden běžný. Okenní manažer i3. A je to naprosto super. Běžný notebook by na to neměl výkon a problém by mohl být dát tam tolik paměti.

Nechápu jak může někdo běžně pracovat jen s běžným notebookem bez externího monitoru.  Pokud potřebuji pracovat na více věcech zároveň, nebo je problém složitější, prostě ta větší pracovní plocha možnost mít až čtyři okna zobrazené zároveň je velká výhoda.

103

Odkladiště / Re:Jedná se o phishing?

« kdy: 31. 01. 2021, 12:24:02 »

Bylo by dobré se naučit číst a ne hned zbrkle reagovat Jinak znovu - u kterého obchodníka lze zaplatit pouhým zadáním čísla karty bez toho, že se musí zadávat i platnost karty a CRC?

Číslem platební karty myslím i všechny ty další potřebné věci k platbě, protože ty se zadávají vždy také včetně podvodných stránek.

104

Odkladiště / Re:Jedná se o phishing?

« kdy: 31. 01. 2021, 12:22:10 »

Defaultní správce hesel v Google chrome se chová nebezpečně. Protože veškerá uložená hesla ukáže každému, kdo si na chvilku sedne k vašemu počítači. Pokud se do vašeho počítače dostane trojský kůň nebo vir, okamžitě může poslat všechny uložená hesla bez toho, aby čekal až je zadáte. Proto ukládání hesel nemají banky rády. Výhoda, že na podvodné stránce budete muset heslo zadat znovu a ručně je nic moc.

A když nechám otevřené dveře do baráku nebo u auta, tak je taky dost pravděpodobné, že tam někdo ukradne na co zrovna natrefí. Stejně, jako když svůj klíč budu půjčovat všem co znám nebo mít zámek, který se dá otevřít šperhákem. Holt základní zásady bezpečnosti se musí dodržovat všude, internet nevyjímaje.

V tomto případě ale nechává dveře otevřené Google a lidí co si otevřené dveře sami zazdí je málo. Banky a všichni ostatní to musí brát jako fakt.

105

Odkladiště / Re:Jedná se o phishing?

« kdy: 31. 01. 2021, 12:20:39 »

[Jestli nějaký obchodník neumí (nechce) 3D Secure a podporuje i platby bez tohoto ověření, tak je pak na něm, aby se případně vypořádal s tím, když mu někdo zaplatí kradenou kartou a bude se následně s bankou dohadovat. Každý normální obchodník v ČR ale podporu 3D Secure má.

Z pohledu zákazníka je to pak naprosto jednoduché - platit kartou pouze tam, kde 3D Secure je. Případně na platby bez 3D Secure - pokud má tedy někdo potřebu platit v obchodech, kde to podporováno není - používat jinou platební kartu, u které se v bance povolí platba a po provedené transakci se platby přes internet zablokují.

V EU je 3D secure povinná. Mimo EU je 3D secure naopak neobvyklá navíc se s jistotou  nedozvím předem, jestli bude 3D secure použita. A i pokud bych se takovým místům úplně vyhnul (což nejde), klidně tam mojí  kartou může platit ten podvodník.  A to je ten hlavní problém. Pokud si toho nevšimnu do týdne nebo čtrnácti dní, mám prostě smůlu. Pokud si toho všimnu, ani pak nemám jisté, že peníze dostanu zpět, protože české banky jsou prostě hloupé a pomalé a nemají ponětí o reálném nebezpečí na internetu.
Ano řešením si je platby povolovat jen na chvíli, nebo mít kartu na jiném než hlavním účtu, kde je nízká částka. Ale to naprostá většina lidí nedělá. Úplně nejlepší je funkce České spořitelny, která generuje jednorázové platební karty vždy jen na jedno použití v mobilní aplikaci.