Új hozzászólás Aktív témák

• #20906 VikMorroHun őstag JoinR #20903

  Új Válasz 2025-10-09 21:34:39 #20906

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  VikMorroHun

  őstag

  válasz JoinR #20903 üzenetére

  Alakul a dolog. A pár száz byte-os logból sikerült 12 KB-osat csinálni.

• #20905 inf3rno nagyúr dabadab #20901

  Új Válasz 2025-10-05 15:43:01 #20905

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  inf3rno

  nagyúr

  válasz dabadab #20901 üzenetére

  Hát benchmarknál arra gondoltam, hogy beviszek 10 millió rekordot, aztán beküldök újabb 10 milliót úgy, hogy abból 50k ami tényleges változtatás. Nagyjából valami ilyesmire lehet készülni, max 25 millióra. Igazából a 100 az ilyen hasraütésre született vagy nem tudom mi volt a megfontolás mögötte, simán lehet, hogy 1000 vagy 10000 lesz helyette, most tervezzük újra a rendszert.

• #20904 inf3rno nagyúr coco2 #20899

  Új Válasz 2025-10-05 15:40:35 #20904

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  inf3rno

  nagyúr

  válasz coco2 #20899 üzenetére

  Nem akarok itt komplett SQL-t írni. Nagyjából úgy néz ki, hogy a SELECT-be rakok egy JSON-t a 100 értékről, azt beparsolja, aztán INNER JOIN-al illesztem a meglévő táblára az értékeket az ON részében meg lesznek a kulcsok meg az, hogyha az érték eltérő, akkor kerüljön csak kiválasztásra. Az INSERT ON DUPLICATE KEY UPDATE meg erre a kiválasztott halmazra íródik.

  A 3-as jó lenne, de tudok nélküle élni.

  Igazából csak kíváncsi voltam kinek mi a véleménye, megérzése. Így is úgy is le fogom benchmarkolni legalább az első kettőt.

• #20903 JoinR őstag VikMorroHun #20902

  Új Válasz 2025-10-05 15:10:01 #20903

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  JoinR

  őstag

  válasz VikMorroHun #20902 üzenetére

  Van benne egy kis programminghorror vibe.

• #20902 VikMorroHun őstag

  Új Válasz 2025-10-05 14:54:33 #20902

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  VikMorroHun

  őstag

  Ha már log:
  A programom 8-10 példányban fut egyszerre, de néha egyik-másik meghibásodik valamiért (nem jöttem rá, mitől). Nincs hibaüzenet, nincs összeomlás, egyszerűen csak megáll, és nem csinál semmit. Eléggé véletlenszerű a dolog; tesztelésnél nem jelentkezik, csak élesben, viszont sok pénzbe kerülhet, ha előfordul, úgyhogy csináltam egy kis log filet, amibe folyamatosan irkálják a dolgaikat, és mindegyik tudja ellenőrizni az összes többit. Ha valamelyik azt látja, hogy leállt az egyik, akkor újraindítja. Tök jó, működik (és így az is kiderült, hogy naponta többször is előfordul ez a hiba). Az egyiket én magam állítottam le, mert nincs rá szükség. A naplóban viszont benne maradt, és buzgón "indították is újra" a nem létező programot. Ok, írtam hozzá egy ellenőrző függvényt, hogy ha valami nem létezik, akkor ne akarják újraindítani, akkor se, ha a naplóban van róla adat. Eredmény: csak fél óránként próbálják újraindítani. Néha egy óráig semmi, aztán valamelyiknek megint feltűnik, hogy nini, hiszen ez leállt, akkor újraindítjuk! Ma írtam hozzá egy másik függvényt, ami kiüti a nem létező programhoz tartozó azonosítót a naplóból, hátha így már nem akarják újraindítani. Kíváncsi vagyok, mi lesz a jövő héten.

  Nyilván, ha törlöm a naplót, akkor nincs adat, ami alapján újraindítanák a nem létező programpéldányt, de azért kíváncsi vagyok, sikerül-e végre rendesen megcsinálni...

• #20901 dabadab titán inf3rno #20898

  Új Válasz 2025-10-04 21:12:57 #20901

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz inf3rno #20898 üzenetére

  Teljesen tippre az első tűnik a gyorsabbnak, de 100 értéknél tulajdonképpen mindegy is.

  Ha viszont tényleg le akarod mérni, hogy a te konkrét adatbázisodnál, a te adataiddal melyik a gyorsabb, akkor meg kapcsold be a slowlogot (egy long_query_time=0 után minden query slow querynek fog számítani) és nézd meg.

Új hozzászólás Aktív témák