Padající mysql na VPS

26. 10. 2021 11:55:56

Z pohledu dodavatele služeb je jednodušší navýšit RAM a to proto, že nevi co tam provozujes a ladit to zabere čas.

Pokud máš root pristum sniz parametry MySQL a pak uvidis.... můžeš ladit i aplikaci ladit, ale paradoxně narazil opět na to, že levněji vyjde dokoupit hrubý výkon.

26. 10. 2021 11:55:56

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492692

Mgr. Tomáš Rychetský

(4 hodnocení)

26. 10. 2021 11:57:24

Napsal Tomina10;1633561
Jen se pozeptám, je na disku dostatek místa?

Ano na disku je necelých 6 GB místa. Swap je maximálně ve stovkách MB. Jediné co permanentně dochází je RAM.

---------- Příspěvek doplněn 26.10.2021 v 11:00 ----------

Napsal josef.jebavy;1633563
Z pohledu dodavatele služeb je jednodušší navýšit RAM a to proto, že nevi co tam provozujes a ladit to zabere čas.

Pokud máš root pristum sniz parametry MySQL a pak uvidis.... můžeš ladit i aplikaci ladit, ale paradoxně narazil opět na to, že levněji vyjde dokoupit hrubý výkon.

Root přístup mám. Můžeš mi nastínit které parametry by si snížil? Pomohl by výpis z my.conf? Aplikaci jsem dlouhodobě ladil ještě pod hostingem. Pak jsem si uvědomil, že víc už z ní nevytáhnu, že potřebuju větší výkon. Ten se s VPS dostavil, ale nastal problém kvůli kterému jsem založil toto vlákno.

26. 10. 2021 11:57:24

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492691

TomasX

(4 hodnocení)

26. 10. 2021 12:01:30

ukaž nastavení MySQL, vesměs 1GB je dostatek paměti i pro velké aplikace. Pád spíše signalizuje špatně nastavenou mysql, měla by totiž ideálně odmítnout nové spojení nebo ukončit dotaz předčasně, ne spadnout.

Mrkni na nastavení innodb_buffer_pool_size, innodb_buffer_pool_instances, thread_cache_size, max_connections, query_cache_*, table_*_cache. pokud je sem dáš, řeknu ti, jestli nejsou příliš ustřelené na 1 GB paměti.

Všichni navyšují, já rád optimalizuji.

26. 10. 2021 12:01:30

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492690

Mgr. Tomáš Rychetský

(4 hodnocení)

26. 10. 2021 12:32:18

Napsal TomášX;1633566
ukaž nastavení MySQL, vesměs 1GB je dostatek paměti i pro velké aplikace. Pád spíše signalizuje špatně nastavenou mysql, měla by totiž ideálně odmítnout nové spojení nebo ukončit dotaz předčasně, ne spadnout.

Mrkni na nastavení innodb_buffer_pool_size, innodb_buffer_pool_instances, ve, max_connections, query_cache_*, table_*_cache. pokud je sem dáš, řeknu ti, jestli nejsou příliš ustřelené na 1 GB paměti.

Všichni navyšují, já rád optimalizuji.

Děkuji Ti za konkrétní podnět. V administraci přímo výpis z my.conf nevidím (jen PHP a apache). Skrz SSH mi cat my.cnf vypíše tohle:

# The MariaDB configuration file
#
# The MariaDB/MySQL tools read configuration files in the following order:
# 0. "/etc/mysql/my.cnf" symlinks to this file, reason why all the rest is read.
# 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,
# 2. "/etc/mysql/conf.d/*.cnf" to set global options.
# 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.
# 4. "~/.my.cnf" to set user-specific options.
#
# If the same option is defined multiple times, the last one will apply.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# If you are new to MariaDB, check out https://mariadb.com/kb/en/basic-mariadb-articles/

#
# This group is read both by the client and the server
# use it for options that affect everything
#

# Port or socket location where to connect
# port = 3306
socket = /run/mysqld/mysqld.sock

# Import all .cnf files from configuration directory
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

V těch dalších douborech vidím jen:

Nic jiného tam není. Kde najdu ty proměnné, které si zmiňoval?

26. 10. 2021 12:32:18

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492689

TomasX

(4 hodnocení)

26. 10. 2021 12:43:19

mrkni ještě na soubory v adresářích /etc/mysql/conf.d/ a /etc/mysql/mariadb.conf.d/, podle konfigurace je tam odsud načítá

26. 10. 2021 12:43:19

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492688

Mgr. Tomáš Rychetský

(4 hodnocení)

26. 10. 2021 13:04:57

Napsal TomášX;1633569
mrkni ještě na soubory v adresářích /etc/mysql/conf.d/ a /etc/mysql/mariadb.conf.d/, podle konfigurace je tam odsud načítá

/etc/mysql/mariadb.conf.d # cat 60-local.cnf

# pokud lze postradat 1-2 sekundy zaznamu pri vypadku
innodb_flush_log_at_trx_commit = 2
# avoid double IO buffering
innodb_flush_method = O_DIRECT
# 256MB + 256 * log2(RAM size in GB) ### log2(8GB) = 3 nebo 2^x=yGB
# default 128M
innodb_buffer_pool_size = 1024M
# kazda tabulka v samostatnem souboru - zabrani rustu ib_data a ib_logfile do vysokych hodnot
innodb_file_per_table
innodb_log_file_size=1G

## Cache for disk based temporary files
#aria_pagecache_buffer_size=128M
## If you are not using MyISAM tables directly (most people are using InnoDB)
#key_buffer_size=64K
## If you have a lot (> 128) of simultaneous running fast queries, you should consider setting thread_handling to pool_of_threads.
#thread_handling = pool_of_threads
## After setting optimizer_search_depth = 0 (auto) the same query took 0.03 seconds.
#optimizer_search_depth = 0

query_cache_type = 1
query_cache_limit = 1M
query_cache_min_res_unit = 2k
query_cache_size = 80M

tmp_table_size= 64M
max_heap_table_size= 64M

#wait_timeout=60

# Enable the slow query log to see queries with especially long duration 
#slow_query_log 
#slow_query_log_file = /var/log/mysql/mariadb-slow.log 
#long_query_time = 1 
#log_slow_rate_limit = 1000 
#log_slow_verbosity  = query_plan 
#log-queries-not-using-indexes

Nevím, který ten soubor je správný. Tohle už ale vypadá jako nastavení mysql. Je to v pořádku?

26. 10. 2021 13:04:57

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492687

TomasX

(4 hodnocení)

26. 10. 2021 13:18:08

ano, správné voloviny jsou v tom 60-local.cnf. Je to dost nesouměrné, ten kdo to nastavoval nejspíš šel POG (pokus, omyl, google).

U innodb_buffer_pool_size je komentář jak došel k výsledku, sám v tom komentáři píše, že to je varianta spíše pro 8 GB paměti, teď je tam nastaveno 1024M, což je strašně moc. Tady bych nastavil 512M a explicitně přidal innodb_buffer_pool_instances=1. Nastavení innodb_flush_method= O_DIRECT je nebezpečné pokud nepoužíváš diskový řadič s baterii, pokud máš obyčejné vps, raději bych tam tuhle hodnotu nedával, sice dojde k lehkému zpomalení, ale ztráta dat při výpadku je větší ztráta.

U innodb_file_per_table chybí hodnota, je to tedy syntax error, podle komentáře by tam mělo být innodb_file_per_table=1.

query_cache_size=80M je příliš vysoká na tvoji kapacitu, snížil bych to na max. 10M.

Tj. v první řadě bych doporučil udělat tyhle změny:

To by ti mělo minimalizovat pády mysql/mariadb na serveru s 1GB paměti. Zároveň bys měl sledovat jaký to bude mít vliv na aplikaci, nemělo by se snížit výkonnost databáze. Další ladění je možné, ale tam je potřeba již znát způsob používání databáze, velikosti dat a dotazů. Teď jsem řešil pouze, aby se databáze paměťově vešla na server.

26. 10. 2021 13:18:08

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492686

Mgr. Tomáš Rychetský

(4 hodnocení)

26. 10. 2021 13:50:33

Napsal TomášX;1633572
ano, správné voloviny jsou v tom 60-local.cnf. Je to dost nesouměrné, ten kdo to nastavoval nejspíš šel POG (pokus, omyl, google).

U innodb_buffer_pool_size je komentář jak došel k výsledku, sám v tom komentáři píše, že to je varianta spíše pro 8 GB paměti, teď je tam nastaveno 1024M, což je strašně moc. Tady bych nastavil 512M a explicitně přidal innodb_buffer_pool_instances=1. Nastavení innodb_flush_method= O_DIRECT je nebezpečné pokud nepoužíváš diskový řadič s baterii, pokud máš obyčejné vps, raději bych tam tuhle hodnotu nedával, sice dojde k lehkému zpomalení, ale ztráta dat při výpadku je větší ztráta.

U innodb_file_per_table chybí hodnota, je to tedy syntax error, podle komentáře by tam mělo být innodb_file_per_table=1.

query_cache_size=80M je příliš vysoká na tvoji kapacitu, snížil bych to na max. 10M.

Tj. v první řadě bych doporučil udělat tyhle změny:

innodb_buffer_pool_instances=1 innodb_buffer_pool_size=512 query_cache_size=10M

To by ti mělo minimalizovat pády mysql/mariadb na serveru s 1GB paměti. Zároveň bys měl sledovat jaký to bude mít vliv na aplikaci, nemělo by se snížit výkonnost databáze. Další ladění je možné, ale tam je potřeba již znát způsob používání databáze, velikosti dat a dotazů. Teď jsem řešil pouze, aby se databáze paměťově vešla na server.

Zajímavé, čekal bych že to poměrně drahý VPS bude mít vyřešené líp (je to defaultní nastavení). Zřejmě chtějí, aby si člověk automaticky přikoupil RAM, pokud tomu nerozumí. Koupil jsem si VPS se 2GB a nastavené to je pro stroj s 8GB.

Nastavil jsem to jak si psal a po restartu to vypadá jako na screenshotu. Do 1GB by se to stejně nevešlo. Uvidíme, co to bude dělat dál. Dám vědět jak to dopadlo. Zatím Ti děkuji a ostatním co se snažili poradit taky.

26. 10. 2021 13:50:33

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492685

Jamira40

(4 hodnocení)

26. 10. 2021 13:57:50

V prípade že to je predavané ako Root VPS a je tam maximálne predinštalovaný software tak všetko v poriadku a cena nemá absolútne čo robiť s nastavením serveru.

26. 10. 2021 13:57:50

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492684

Mgr. Tomáš Rychetský

(4 hodnocení)

26. 10. 2021 14:08:22

Napsal Jamira40;1633575
V prípade že to je predavané ako Root VPS a je tam maximálne predinštalovaný software tak všetko v poriadku a cena nemá absolútne čo robiť s nastavením serveru.

Ok, mozna je to bezna praxe, ale urcite by bylo fajn mit konfiguraci dle zakoupeneho vykonu. V cene je support, ktery mi pri dotazu "proč restartuje mysql" napsal "je potřeba dokoupit RAM". Kdyby mi napsal, musíte si server překonfigurovat na 2GB, defaultně je nakonfigurován na 8GB, tak neřeknu ani popel.

Takto mi to za službu s tímto výkonem za cenu necelých 4000 v pořádku nepřijde. Nebo v čem je podle Vás výhoda si platit za 1CPU 2GB RAM 40GB disk 4000, když Vám nikdo neporadí jako u root serveru za poloviční cenu?

26. 10. 2021 14:08:22

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492683

Mgr. Tomáš Rychetský

(4 hodnocení)

26. 10. 2021 14:10:52

Ještě posílám výpis z htop.

26. 10. 2021 14:10:52

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492682

TomasX

(4 hodnocení)

26. 10. 2021 14:43:08

podle screenu ale vidím, že mariadb bere kolem 700 - 800 MB, což by mělo být v pořádku, co mi nedochází?

26. 10. 2021 14:43:08

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492681

Mgr. Tomáš Rychetský

(4 hodnocení)

26. 10. 2021 14:58:42

To jsem jen dodal výpis, protože ho po mě někdo chtěl. Jestli je v souladu s tím co si psal, tak to je v pořádku:).

26. 10. 2021 14:58:42

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492680

TomasX

(4 hodnocení)

26. 10. 2021 15:26:23

podle mě to je v souladu, pokud jsi změnil nastavení a takhle to vypadá s pamětí, je to očekávané. Mělo by to přestat padat, je to sice taková střelba na slepo, ale mohlo by to stačit. Původní nastavení nebylo zrovna nejlepší, nemluvě o té řadě dalších chyb, které sice nemají takový přímý vliv na celkovou spotřebu paměti, ale spíše ukazují, že konfigurace není optimální.

26. 10. 2021 15:26:23

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492679

HonzaIT

(6 hodnocení)

26. 10. 2021 15:36:32

Napsal tomasr;1633577
Ok, mozna je to bezna praxe, ale urcite by bylo fajn mit konfiguraci dle zakoupeneho vykonu. V cene je support, ktery mi pri dotazu "proč restartuje mysql" napsal "je potřeba dokoupit RAM". Kdyby mi napsal, musíte si server překonfigurovat na 2GB, defaultně je nakonfigurován na 8GB, tak neřeknu ani popel.

Takto mi to za službu s tímto výkonem za cenu necelých 4000 v pořádku nepřijde. Nebo v čem je podle Vás výhoda si platit za 1CPU 2GB RAM 40GB disk 4000, když Vám nikdo neporadí jako u root serveru za poloviční cenu?

Hukot nebo Contabo :) za 4K je tato konfigurace fakt úlet :)

Virtual Private Servers | Quality VPS at Incredible Price | Contabo

26. 10. 2021 15:36:32

https://webtrh.cz/diskuse/padajici-mysql-na-vps/strana/2#reply1492678