Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Představen byl notebook TUXEDO InfinityBook Pro 15 Gen10 s procesorem AMD Ryzen AI 300, integrovanou grafikou AMD Radeon 800M, 15,3 palcovým displejem s rozlišením 2560x1600 pixelů. V konfiguraci si lze vybrat až 128 GB RAM. Koupit jej lze s nainstalovaným TUXEDO OS nebo Ubuntu 24.04 LTS.
Zdravim, mam MySQL v 3 uzlech pomoci master-master replikace Percona xtradb cluster.
Vse beha v poho az do chvile kdy po nejake dobe insertne zaznam do db ktera ma neco kolem 300 zaznamu. V tuto chvili se postupne zatizi vsechny tri uzle replikace a prestanou reagovat na par desitek vterin repsektive kousne se cela aplikace.
Ale nad touto tabulkou se provadi relativne dost SELECTu radove desitky za vterinu.
Myslim ze to muze delat velka hodnota query-cache-size ale s mensi hodnotou bylo zase hodne prunes per day.
Dokaze nekdo prosim nakopnout spravnym smerem co hledat?
V logu mam pak neco v tomto duchu (Uvedena table v logu nize nesouvisi prave s tou ve ktere se provedl insert)
*** Priority TRANSACTION: TRANSACTION 393262833, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 1 lock struct(s), heap size 360, 0 row lock(s) MySQL thread id 7, OS thread handle 0x7f255962e700, query id 299104427 invalidating query cache entries (table) *** Victim TRANSACTION: TRANSACTION 393257917, ACTIVE 114 sec mysql tables in use 1, locked 1 2 lock struct(s), heap size 360, 1 row lock(s), undo log entries 1 MySQL thread id 25482552, OS thread handle 0x7f252e134700, query id 299095466 localhost 127.0.0.1 database_sys wsrep in pre-commit stage UPDATE `table` SET `record`=1.5655388889 WHERE (`table`.`id` = 10776) *** WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 4039 page no 126 n bits 176 index `PRIMARY` of table `database`.`table` trx id 393257917 lock_mode X locks rec but not gap 2015-02-26 22:47:53 58270 [Note] WSREP: cluster conflict due to high priority abort for threads: 2015-02-26 22:47:53 58270 [Note] WSREP: Winning thread: THD: 7, mode: applier, state: executing, conflict: no conflict, seqno: 33153378 SQL: (null) 2015-02-26 22:47:53 58270 [Note] WSREP: Victim thread: THD: 25482552, mode: local, state: committing, conflict: no conflict, seqno: -1 SQL: UPDATE `table` SET `record`=1.5655388889 WHERE (`table`.`id` = 10776)
Pro MySQL je nasledujici konfigurace
[mysqld]
innodb_use_native_aio=0
datadir = /var/lib/mysql
pid-file = /var/run/mysqld/mysqld.pid
key-buffer-size = 32M
myisam-recover = FORCE,BACKUP
max-allowed-packet = 16M
max-connect-errors = 1000000
innodb = FORCE
tmp-table-size = 32M
max-heap-table-size = 32M
max-connections = 500
thread-cache-size = 50
open-files-limit = 65535
table-definition-cache = 1024
table-open-cache = 2048
log-error = /var/log/mysql/error.log
log-queries-not-using-indexes = 0
slow-query-log = 0
slow-query-log-file = /var/log/mysql/slow.log
# CACHES AND LIMITS #
#table_cache = 16000
tmp-table-size = 256M
max-heap-table-size = 256M
query-cache-type = 1
query-cache-size = 2048M
max-connections = 2000
thread-cache-size = 50
open-files-limit = 65535
table-definition-cache = 8000
table-open-cache = 8000
key_buffer_size = 256M
join_buffer_size = 512k
thread_cache_size = 15000
table_definition_cache = 16384
table_open_cache = 16384
innodb_write_io_threads = 16
innodb_read_io_threads = 16
back_log = 2048
# INNODB #
innodb_lock_wait_timeout = 60
innodb_buffer_pool_instances = 8
innodb_rollback_on_timeout = 0
innodb-flush-method = O_DIRECT
innodb-log-files-in-group = 2
innodb-log-file-size = 128M
#innodb-flush-log-at-trx-commit = 1
innodb-file-per-table = 1
innodb-buffer-pool-size = 4096M
innodb-flush-log-at-trx-commit = 0
[--] Up for: 18d 2h 26m 48s (258M q [165.038 qps], 23M conn, TX: 164B, RX: 39B)
[--] Reads / Writes: 69% / 31%
[--] Total buffers: 6.5G global + 1.4M per thread (800 max threads)
[OK] Maximum possible memory usage: 7.6G (48% of installed RAM)
[OK] Slow queries: 0% (4K/258M)
[OK] Highest usage of available connections: 34% (275/800)
[OK] Key buffer size / total MyISAM indexes: 256.0M/102.0K
[OK] Key buffer hit rate: 100.0% (171M cached / 4 reads)
[OK] Query cache efficiency: 46.5% (89M cached / 192M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (3K temp sorts / 15M sorts)
[OK] Temporary tables created on disk: 0% (1K on disk / 11M total)
[OK] Thread cache hit rate: 99% (308 created / 23M connections)
[OK] Table cache hit rate: 87% (3K open / 4K opened)
[OK] Open file limit used: 0% (18/33K)
[OK] Table locks acquired immediately: 99% (166M immediate / 166M locks)
[!!] InnoDB buffer pool / data size: 4.0G/5.0G
[OK] InnoDB log waits: 0
[--] Up for: 18d 2h 26m 48s (258M q [165.038 qps], 23M conn, TX: 164B, RX: 39B)
[--] Reads / Writes: 69% / 31%
[--] Total buffers: 6.5G global + 1.4M per thread (800 max threads)
[OK] Maximum possible memory usage: 7.6G (48% of installed RAM)
[OK] Slow queries: 0% (4K/258M)
[OK] Highest usage of available connections: 34% (275/800)
[OK] Key buffer size / total MyISAM indexes: 256.0M/102.0K
[OK] Key buffer hit rate: 100.0% (171M cached / 4 reads)
[OK] Query cache efficiency: 46.5% (89M cached / 192M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (3K temp sorts / 15M sorts)
[OK] Temporary tables created on disk: 0% (1K on disk / 11M total)
[OK] Thread cache hit rate: 99% (308 created / 23M connections)
[OK] Table cache hit rate: 87% (3K open / 4K opened)
[OK] Open file limit used: 0% (18/33K)
[OK] Table locks acquired immediately: 99% (166M immediate / 166M locks)
[!!] InnoDB buffer pool / data size: 4.0G/5.0G
[OK] InnoDB log waits: 0
Nejjednodušším způsobem, jak se vyhýbat deadlocku, je zamykání tabulek vždy ve stejném pořadí, či používání enginu InnoDB, který deadlocky sám detekuje.InnoDB mam vsude bez vyhrady, vyuzivam Foreign keys..
mysql> SHOW GLOBAL STATUS LIKE 'innodb_deadlocks'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | Innodb_deadlocks | 0 | +------------------+-------+ 1 row in set (0,11 sec)
Kdyz jsem na to koukal tak deadlocky se stavaji na tabulkach ktery by nemeli mit s tim nic spolecneho..
Problem nastane kdyz pridam zaznam do tabulky se seznamem uzivatelskych blokaci (ktere se nactou pri kazdem hitu prihlaseneho uzivatele), ma 4 cizi klice (2 z toho vedou na stejnou tabulku uzivatelu ktera se prakticky neaktualizuje + jeden ktery je ne-vzdy vyplneny vede na tabulku zaznamu pokud se blokace zapisuje jeste do zvlastni tabulky tzn blokace je vyssi urovne administratorem a posledni klic vede na tabulku tez taky se seznamem ktery neni aktualizovan tak casto ani a hlavne ne pri vlozeni blokace). PK je pouze na ID sloupec, tzn PK + 4 IK s FK.
Zkusim se mrknout na ten link a povolim verbose logovani locku snad z toho budu moudrejsi jsem z toho uz trochu zmateny, k percone jsem nasel i toto v toolkitu - http://www.percona.com/doc/percona-toolkit/2.1/pt-deadlock-logger.html
Po nejakem case tu mam maly update. Nyni mi percona jede single v jednom boostrap-pxc uzlu a problem s tou tabulkou je neustale. Takze timto odpada teorie o problemu v (nebo při) replikaci
Nize posilam schema tabulky. 3 IK+FK a 1 PK s AI. Aktualni pocet zaznamu 387. Kdyz to necham pul dne odlezet a udelam insert tak mysql prestane reagovat na 10s. Kdyz pote udelam hned dalsi tak vse ok.
CREATE TABLE `mistnosti_zakazy` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `uzivatel_id` INT(11) NULL DEFAULT NULL, `mistnost_id` INT(11) NULL DEFAULT NULL, `ip` VARCHAR(15) NULL DEFAULT NULL COLLATE 'utf8_czech_ci', `kolikrat` TINYINT(4) NULL DEFAULT '0', `typ` INT(11) NULL DEFAULT NULL, `duvod` VARCHAR(1000) NULL DEFAULT NULL COLLATE 'utf8_czech_ci', `od_id` INT(11) NULL DEFAULT NULL, `do` DATETIME NULL DEFAULT NULL, `trest_id` INT(11) NULL DEFAULT NULL, PRIMARY KEY (`id`), INDEX `FK__uzivatele` (`uzivatel_id`), INDEX `FK__mistnosti` (`mistnost_id`), INDEX `FK_mistnosti_zakazy_uzivatele` (`od_id`), INDEX `FK_mistnosti_zakazy_uzivatele_tresty` (`trest_id`), CONSTRAINT `FK_mistnosti_zakazy_mistnosti` FOREIGN KEY (`mistnost_id`) REFERENCES `mistnosti` (`id`) ON UPDATE CASCADE ON DELETE CASCADE, CONSTRAINT `FK_mistnosti_zakazy_uzivatele` FOREIGN KEY (`uzivatel_id`) REFERENCES `uzivatele` (`id`) ON UPDATE CASCADE ON DELETE CASCADE, CONSTRAINT `FK_mistnosti_zakazy_uzivatele_2` FOREIGN KEY (`od_id`) REFERENCES `uzivatele` (`id`) ON UPDATE CASCADE ON DELETE CASCADE, CONSTRAINT `FK_mistnosti_zakazy_uzivatele_tresty` FOREIGN KEY (`trest_id`) REFERENCES `uzivatele_tresty` (`id`) ON UPDATE CASCADE ON DELETE CASCADE ) COLLATE='utf8_czech_ci' ENGINE=InnoDB AUTO_INCREMENT=11039 ;
Tiskni
Sdílej: