@dba_ru

Страница 421 из 718
Alexey
15.02.2018
10:30:25
Коллеги, есть один сервер (виртуалка) с mysql 5.6. Общий объем оперативки 4Gb. innodb_buffer_size=2G. Замечаю, что процесс mysql примерно 89Mb держит в свопе. Нормальная ли это ситуация или нужно что-то менять?
Это зависит от настройки ядра vm.swappiness. Возможно стоит уменьшить до минимума (типа 1), если на серваке кроме mysql больше ничего нет.

Dmitry
15.02.2018
10:39:18
Это зависит от настройки ядра vm.swappiness. Возможно стоит уменьшить до минимума (типа 1), если на серваке кроме mysql больше ничего нет.
имеет ли смысл вообще отказаться от своп? На продакшн серверах с галерка-кластер у меня сервера с 192гб ram и inno_db_pool_size=160гб прекрасно обходятся без свопа. По идее ведь скуль не может слопать больше выделенных ему 2гб?

Alexey
15.02.2018
10:40:35
не может слопать больше выделенных ему 2гб? Если только не потечёт или будет какой-то другой форсмажор. Реальный объем памяти, который сожрёт mysql зависит же от многих параметров, не только от размера buffer pool

Google
Alexander
15.02.2018
10:42:40
а 2 гига - это только innodb pool, дополнительно будет кушать память под table cache, query cache, key cache, connections etc.

Dmitry
15.02.2018
10:50:41
Понял, спасибо!

Art
15.02.2018
15:12:41
вы тут за вопрос про rpoxysql не побьёте?

тушу реплику, в proxysql ее статус переходит в SHUNNED, но запросы которые попадают в query_rule прицеленные на группу с этим хосто (он там единственный) так и продалжают туда ломиться и не переходят в другую группу. Я понимаю что не так как то приготовил его, но в упор не вижу в чем проблема

lost
15.02.2018
15:26:45
а разве proxysql умеет с учётом реплики проксировать?

с учётом её статуса, если быть точным

Art
15.02.2018
15:32:13
ну а к чему тогда этот статус? мониторинг и т.д?

Devsp
16.02.2018
09:58:31
Современный учебник JavaScript 2017г.

Vladislav
16.02.2018
09:59:31
@AlexCAD ?

чую, что там не учебник

Олег
16.02.2018
10:24:19
чую, что там не учебник
да не, 3 файла в формате epub

Vladislav
16.02.2018
10:24:47
удачи

Google
Олег
16.02.2018
10:25:19
ну, как минимум, книжки внутри точно есть

Anatoly
16.02.2018
13:29:00
народ, привет,кто решал подобную проблему DatabaseMail перестал отправлять письма... просто в один прекрасный момент, ни test email ни ежедневные и такая проблема на 6 серверах - stg environment tst - работает prd - работает Логах пусто: DatabaseMail process is started DatabaseMail process is shutting down

Red
16.02.2018
13:33:44
общий привет! есть база ms sql 2012. база work в состоянии restoring. джобом делаю рестор логов в базу. в истории джоба пишет что рестор прошел успешно и лог втянулся. пытаюсь посмотреть историю рестора за последний час: select * from msdb..restorehistory where destination_database_name='WORK' and restore_type='L' and restore_date > DATEADD (minute , -60, getdate() ) и вижу что данных нет. последние данные в msdb..restorehistory за 01-02-2018. Как это пофиксить подскажите?

Артур Евгеньевич
16.02.2018
14:19:36
Парни а если select for update выполняется в рамках транхакции и не находит записи, он всю таблицу блокирует?

Виктор
16.02.2018
14:47:05
Нет вся таблица не блокируется

Артур Евгеньевич
16.02.2018
14:48:02
но у меня получается что блокирует

begin 1 begin 2 select for update 1 select for update 2 (не блокируется предыдущим ) insert 1 - встает в очередь за "select for update 2" insert 2 deadlock из-за "select for update 1"

оба селекта запрашивают по одному и тому же условию и оба не удачные

Al
16.02.2018
14:57:11
оба селекта запрашивают по одному и тому же условию и оба не удачные
Не удачные запросы... ты там в лотерею играешь? Не знаешь что в базе лежит? Пусть мне повезет?

Артур Евгеньевич
16.02.2018
14:58:40
Не удачные запросы... ты там в лотерею играешь? Не знаешь что в базе лежит? Пусть мне повезет?
Что значит повезет? Делаем запрос есть ли пользователь в определенной таблице, если нет, то вставляем его. Но собтия добавления пользователя в эту таблицу разгребаются многопоточным демоном, из за чего и возникает вот этахерь с взаимоблокировками

Al
16.02.2018
15:00:48
Артур Евгеньевич
16.02.2018
15:02:08
ты что то любишь фантазирвоать я смотрю

Al
16.02.2018
15:14:02
Я так понял, у него select for update на одну таблицу в разных(?) транзакциях
я так понял что у него там какой то бред и он сам мало понимает как и зачем оно у него работает

Al
16.02.2018
15:15:37
Еженедельная рубрика "Пятничный оракул" :)
ну так нужно же где то тренировать ясновиденье

Pavel
16.02.2018
15:16:40
оба селекта запрашивают по одному и тому же условию и оба не удачные
Вот меня тут смущает, ты одну и ту же строку пытаешься в двух транзакциях одновременно проапдейтить?

lost
16.02.2018
15:17:12
не проапдейтить он хочет

Google
lost
16.02.2018
15:17:28
он хочет внутри мускуля систему очередей сделать

так как топикстартер никакой конкретики не дал кроме подобия запросов - рискну предположить, что там хватит обычного upsert

Al
16.02.2018
15:20:34
так как топикстартер никакой конкретики не дал кроме подобия запросов - рискну предположить, что там хватит обычного upsert
ты забыл про волшебного демона который в 100500 потоков делает апдейт в одной таблице

Ilia
16.02.2018
15:22:03
Парни а если select for update выполняется в рамках транхакции и не находит записи, он всю таблицу блокирует?
Вообще-то он блокирует только записи, которые нужно будет изменить . И.е. если ничего не нашел, то ничего и не заблокировал.

lost
16.02.2018
15:22:52
не вноси смуту

Ilia
16.02.2018
15:23:07
Парни а если select for update выполняется в рамках транхакции и не находит записи, он всю таблицу блокирует?
Но в процессе поиска запрос может дополнительно временно что-то блокировать, на разных СУБД может быть по разному

блокирует он записи, которые имеются, а не которые нужно изменить
Так именно эти записи запрос и должен вернуть

lost
16.02.2018
15:24:38
а вот тут уже будет интересно

lost
16.02.2018
15:25:07
:)

Al
16.02.2018
15:25:20
... то НЕ ПРОАПДЕЙТИТ!
гениально, КЭП!

lost
16.02.2018
15:25:43
там есть ещё прикольнее костыли... get_lock называются

Ilia
16.02.2018
15:25:43
Служу!

Al
16.02.2018
15:26:01
Служу!
вольно, разойдись

Al
16.02.2018
15:27:26
там есть ещё прикольнее костыли... get_lock называются
прикольные костыли, это когда создается 100500 одинаковых строк в разных потоках а потом база все лишнии удаляет

Google
Al
16.02.2018
15:30:52
lost
16.02.2018
15:33:50
скорее всего там не на уники смотреть надо, а на foreign keys, на вставке будет проверка оного, и не получется shared lock кинуть на строку, которая обновлена в другой транзакции

Al
16.02.2018
15:36:08
скорее всего там не на уники смотреть надо, а на foreign keys, на вставке будет проверка оного, и не получется shared lock кинуть на строку, которая обновлена в другой транзакции
не так. я тут вот на кофейной гуще увидел, как раз завтрактаь закончил и кофе допил. вся проблема в том что товарищ не продумал логику своего приложения, завел там каких то демонов которые валят все подряд. при этом не имеется никакой логики обработки запросов от клиентов

логично что в несколько потоков они лочат все подряд

lost
16.02.2018
15:36:43
демоны эти...

клятые

Al
16.02.2018
15:36:57
угу тут экзорцист нужен

Pavel
16.02.2018
15:40:02
С одним и тем же условием? Т.е выгребается одно и то же?

Артур Евгеньевич
16.02.2018
15:40:13
Вот меня тут смущает, ты одну и ту же строку пытаешься в двух транзакциях одновременно проапдейтить?
не проапдейтить, а посмотреть есть ли пользователь в таблице и ели нет добавить его

Вообще-то он блокирует только записи, которые нужно будет изменить . И.е. если ничего не нашел, то ничего и не заблокировал.
ты попробуй на практике) два терминала открой и запусти в той последовательности как я указал

С одним и тем же условием? Т.е выгребается одно и то же?
да нихрена не выгребается, empty set возвращается

Al
16.02.2018
15:41:25
ты попробуй на практике) два терминала открой и запусти в той последовательности как я указал
ты попробуй на практике сделать логику перед тем как мучить базу. что бы по одному и тому же запросы не было 100500 тридов

да нихрена не выгребается, empty set возвращается
а с хренали ли оно выгребется если комита не было?

Alex
16.02.2018
15:46:35
Привет. Вопрос. Есть сервер средненький (без VDS), есть десяток таблиц по 3 тыс строк. И библиотека ML для php, которая работает с ними. На каком этапе нужно будет это все переносить на сервак с большей мощностью и подключать норм ML обработку, если часть ф-ций считается на лету.

Pavel
16.02.2018
15:49:52
А эта конструкция в мускуле разве не читает самые свежие данные? И пока транзакция не зафиксирована мы будем ее ждать?

lost
16.02.2018
15:50:05
ml это типа machine learning ?

Al
16.02.2018
15:50:55
А эта конструкция в мускуле разве не читает самые свежие данные? И пока транзакция не зафиксирована мы будем ее ждать?
вот у меня тоже есть такое подозрение что пкоа коммит не прошел то таблица на локе стоит целиком

Google
Alex
16.02.2018
15:51:06
ml это типа machine learning ?
типа да. есть такое https://php-ml.readthedocs.io/en/latest/math/statistic/ если кому интересно

А эта конструкция в мускуле разве не читает самые свежие данные? И пока транзакция не зафиксирована мы будем ее ждать?
данные постоянно добавляются и при открытии страницы на клиенте происходит расчет и отображается актуальные данные

Al
16.02.2018
15:56:32
что в принципе не удивительно. он пытается вытащить с таблицы то чего там нет и видимо перебирает все строки вешая на них лок по порядку :)

Pavel
16.02.2018
15:58:04
SELECT ... FOR UPDATE For index records the search encounters, locks the rows and any associated index entries, the same as if you issued an UPDATE statement for those rows. Other transactions are blocked from updating those rows, from doing SELECT ... LOCK IN SHARE MODE, or from reading the data in certain transaction isolation levels.

Pavel
16.02.2018
15:59:59
Мы ситуацию Артура обсуждаем, я не уверен, что это относилось к тебе ) Но если помогло, то отлично.

lost
16.02.2018
16:12:39
не заблокирует он пустоту, не ссыте

Страница 421 из 718