abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 0
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 19
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 767 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Percona MySQL a problem s Insertem do male tabulky

26.2.2015 23:12 LuRy | skóre: 12
Percona MySQL a problem s Insertem do male tabulky
Přečteno: 1092×

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

Statistiky MysqlTuner z jednoho uzlu je nasledujici (Hodnota momentalniho innodb poolu neni puvodcem problemu, tento problem se projevoval i pred prevysenim hodnoty poolu)

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

Odpovědi

rADOn avatar 17.3.2015 16:18 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Nemas nahodou problem s timhle?
"2^24 comments ought to be enough for anyone" -- CmdrTaco
20.3.2015 07:55 Kazatel
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Tezko takhle soudit, ale taky bych se priklanel k deadlocku. Chovani tomu odpovida.

Pri selectu a insertu resis explicitne zamky?
21.3.2015 01:45 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Zamky tabulek vubec neresim, nechavam to na MySQL samotny.. pojem deadlock jsem tusim ze nekde v logu zaznamenal ale ne tak abych se tim zabyval nebo jsem o tom nevedel.. Co bych si mel zjistit a pripadne jak se proti tomu nejak opatrit?

Ta situace je docela zvlastni, velky tabulky v radu GB se zapisy/cteni nemaji vubec problem ale mala tabulka (ktera ma sice 2 cizi klice) problem jako krava..
21.3.2015 01:55 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Z jednho PDF maturitních témat tvrdí toto:
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..
okbob avatar 21.3.2015 13:12 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Detekce deadlocků má každá databáze - ještě pokud zamykáte s granularitou na úrovni tabulek, tak jim lze předejít. Ale v okamžiku, kdy zamykáte s granularitou řádků, tak předcházení deadlocků je dost složité, a ne vždy se to podaří. Nicméně detekce deadlocku vyřeší pouze to, že se aplikace nekousne nafurt - nicméně deadlock znamená minimálně 1sec čekání na zámek, a příliš mnoho deadlocků znamená dost pomalou aplikaci. Skutečným řešení je a) změna schématu, b) zrychlení operací, aby nedošlo k souběhu zámků.
21.3.2015 14:09 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
No technicky select trva nejvyse par ms. Zamky vlastne ani transakce aplikacne nijak nevyuzivam (nebylo jich treba a vetsinou mam zavisle selecty na predchozim insertu), nechavam to v rezii mysql jestli je nejakym stylem vyuziva sama pri update/insertech. Kazdy z x desitek pozadavku za vterinu dela select do teto tabulky takze me napada ze by tenhle problem mohl nastavat prave kuli tomuto.. Nicmene kdyz se stane tohle zakousnuti trva to klidne i 2 minuty nez se to ozivi a taky se to nestava vzdycky.. Napr pri stejnem poctu uzivatelu poprvy udelam insert tak se to hryzne po tom co se to odhryzne udelam dalsi insert a uz se nic nestane.. Takze prvni muj hint smeroval k nejakymu failu z cache.
21.3.2015 14:23 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
No tak s deadlocky jsem ted hodne na vazkach. Na vsech 3 uzlech

mysql> SHOW GLOBAL STATUS LIKE 'innodb_deadlocks';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Innodb_deadlocks | 0     |
+------------------+-------+
1 row in set (0,11 sec)
21.3.2015 14:34 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Tak deadlocky nee, prolezl jsem log aplikace a narazil na tohle http://502.cz/scr/20150321133355107.png
21.3.2015 18:33 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
beru zpet ... halda lock timeoutu a pak deadlocku .. no otazka je jak tomu ucinne predchazet? nebo proc se to vubec deje? Muze za to ten cluster? skrz haproxy se pristupuje nahodne k jednomu ze tri uzlu tzn jeden uzel muze zapisovat do tabulky a ostatni uzly ve stejnou chvili cist.. ale proc se to nedeje u jinych daleko vice zatizenych a objemnejsich tabulek?
okbob avatar 21.3.2015 18:44 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Na menší tabulce je větší šance, že uživatelé (procesy) si budou snažit přepsat data. Může být za tím také referenční integrita - není dobré často updatovat tabulku, která drží důležité primární klíče. V zásadě je důležité pochopit, co, jak a proč se zamyká, a teprve pak je možné najít řešení. Viz http://www.chriscalender.com/tag/innodb-lock-monitor/.
21.3.2015 18:51 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky

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

25.3.2015 04:25 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Tak dnes v noci jsem delal nejaky vyvoj a pridaval novou tabulku s tim ze u jedne jiz existujici tabulky potrebuju udelat hromadny update jednoho INT sloupce na 0. je v ni asi 30k zaznamu (update jsem provadel primo pres mysql-cli) a po par vterinach to na me vybaflo s deadlockem a to pokazde kdy sem to zkusil.. Musel jsem shodit vsechny 3 uzly nastartovat jeden jako boostrapovy a na nem to udelat a az po tom udelat plnou synchronizaci dalsich 2 uzlu.. Mam pocit ze mam neco nekde pekne blbe
25.3.2015 10:46 Ivan
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Neni mozny ze se tam deje "neco" na urovni stranek? Tzn. ackoliv storage engine pouziva zamykani na urovni radek, tak replikace si vymenuje cele stranky a nastane nejaky problem synchronozaci. (PS: v terminologii Oracle RAC se tomu rika "global enqueue deadlock").
25.3.2015 15:20 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky
Stranky delali behem toho hromadnyho updatu svoje updaty a selecty do tyhle tabulky ale bylo to v noci takze zadny extra zatizeni. Nicmene samotnej ten update trval 4 minuty na 30k zaznamech..
19.6.2015 00:20 LuRy | skóre: 12
Rozbalit Rozbalit vše Re: Percona MySQL a problem s Insertem do male tabulky

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
;

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.