Гена
ок
спасибо)
Ilya
можно запустить рестор с дропаньем старых данных - тогда он затрет и вставит
Гена
там по идее не будет данных вовсе
приложение создаст пустые коллекции и надо туда будет заимпортить
я боюсь, что он поругается на дупликаты
madspectator
020-01-20T13:24:45.141+0000 E STORAGE [initandlisten] WiredTiger error (13) [1579526685:141371][37770:0x7fe28b91cd40], file:index/1-2929297627492655265.wt, WT_SESSION.open_cursor: __posix_open_file, 667: /var/lib/mongodb/index/1-2929297627492655265.wt: handle-open: open: Permission denied Raw: [1579526685:141371][37770:0x7fe28b91cd40], file:index/1-2929297627492655265.wt, WT_SESSION.open_cursor: __posix_open_file, 667: /var/lib/mongodb/index/1-2929297627492655265.wt: handle-open: open: Permission denied
2020-01-20T13:24:45.141+0000 E STORAGE [initandlisten] Failed to open a WiredTiger cursor. Reason: UnknownError: 13: Permission denied, uri: table:index/1-2929297627492655265, config: overwrite=false
2020-01-20T13:24:45.141+0000 E STORAGE [initandlisten] This may be due to data corruption. Please read the documentation for starting MongoDB with --repair here: http://dochub.mongodb.org/core/repair
Как такое может быть? Права проверил, rw для пользователя mongodb. Причём, если запустить просто mongod --config /etc/mongodb.conf от рута, то работает.
yopp
Для dbpath
madspectator
Это есть всё.
madspectator
В конфиге прописано directoryForIndexes: true и collection/ и index/ это симлинки на каталоги на примонтированных дисках. Но на всё и вся стоят права для юзверя mongodb
yopp
В конфиге прописано directoryForIndexes: true и collection/ и index/ это симлинки на каталоги на примонтированных дисках. Но на всё и вся стоят права для юзверя mongodb
Проверьте что на дисках права тоже верные
madspectator
Проверял.
yopp
Проверяйте ещё раз, это не в монге проблема, 13 ошибка это ошибка файлового дескриптора.
Там в трейсе есть путь к файлу, убедитесь что файл имеет нужные права
yopp
Попробуйте под пользователем монги проверить что файлы читаются
yopp
Не знаю, посмотрите что там нет xattr
madspectator
Хм
# su mongodb
This account is currently not available.
Илья
День добрый,
подскажите как можно посмотреть % долгих запросов к коллекции / по коллекциям
компас знаю, но он показывает только то что они есть и какие
в студии тоже ничего такого не нашел
монга 3,6
yopp
Илья
да, в рамках коллекции
Илья
ну или хооотяб вообще всех долгих к вообще всем
вообщем что-нибудь более удобное чем парсить логи для получения долгих avg per sec
потом сравнивать с количеством поступающих в студии
форкать драйвер чтоб встроить мерилки, тоже не особо хочется
yopp
Прямо — наверное никак. Косвенно из статистики курсоров в коллекции и количества упавших в profile коллекцию медленных запросов для вашего «медленно»
Второй вариант это поллинг currentOp, чтоб собрать статистику
yopp
Для второго варианта даже было готовое решение на гитхабе
Илья
спасибо
ill-ya
А какой gui лучше всего для macOS?
yopp
Хм
# su mongodb
This account is currently not available.
su -s /bin/bash mongodb или с любым другим удобным вам шеллом
yopp
у него скорее всего шелл nologin
Evgeniy
Коллеги. Доброго времени суток.
Нужен совет бывалых.
Используем Mongodb v4. (Берём как сервис у mail.ru облако )
Имеется инстанс БД с одной коллекцией. Имеются индэксы одиночные и составные.
На данныей момент коллекция объёмом 280гигов. Это данные начиная с 23 декабря 19 года.
Что заметили. При выборке по коллекции за 10 дней с использование индэксов запросы проходят дольше чем таж база но на мускуле (индексы + партишены и сабпартишен ). Картина такая при увеличение размера коллекции выростает длительность запроса.
Как боросться.? Возможно мы делаем чтот не так. Может ктот совет дать?
Evgeniy
Либо мы не верно выбрали тип БД под наши задачи, либо мы с бд чтот не так делаем.
Evgeniy
Хост под монгу
CPU 8 RAM 16 SSD 1.8 Tb
madspectator
su -s /bin/bash mongodb или с любым другим удобным вам шеллом
То же самое :(
2020-01-20T15:30:14.199+0000 E STORAGE [initandlisten] WiredTiger error (13) [1579534214:199919][1562:0x7f69cb684d40], file:index/1-2929297627492655265.wt, WT_SESSION.open_cursor: __posix_open_file, 667: /var/lib/mongodb/index/1-2929297627492655265.wt: handle-open: open: Permission denied Raw: [1579534214:199919][1562:0x7f69cb684d40], file:index/1-2929297627492655265.wt, WT_SESSION.open_cursor: __posix_open_file, 667: /var/lib/mongodb/index/1-2929297627492655265.wt: handle-open: open: Permission denied
2020-01-20T15:30:14.199+0000 E STORAGE [initandlisten] Failed to open a WiredTiger cursor. Reason: UnknownError: 13: Permission denied, uri: table:index/1-2929297627492655265, config: overwrite=false
2020-01-20T15:30:14.199+0000 E STORAGE [initandlisten] This may be due to data corruption. Please read the documentation for starting MongoDB with --repair here: http://dochub.mongodb.org/core/repair
2020-01-20T15:30:14.200+0000 F - [initandlisten] Fatal Assertion 50882 at src/mongo/db/storage/wiredtiger/wiredtiger_session_cache.cpp 101
2020-01-20T15:30:14.200+0000 F - [initandlisten]
Запускал через
su -l mongodb -s /bin/bash
и потом mongod —config /etc/mongod.cfg
madspectator
О, а вот ls этого файла я не могу из под mongodb юзверя сделать, ща разберёмся :)
yopp
Коллеги. Доброго времени суток.
Нужен совет бывалых.
Используем Mongodb v4. (Берём как сервис у mail.ru облако )
Имеется инстанс БД с одной коллекцией. Имеются индэксы одиночные и составные.
На данныей момент коллекция объёмом 280гигов. Это данные начиная с 23 декабря 19 года.
Что заметили. При выборке по коллекции за 10 дней с использование индэксов запросы проходят дольше чем таж база но на мускуле (индексы + партишены и сабпартишен ). Картина такая при увеличение размера коллекции выростает длительность запроса.
Как боросться.? Возможно мы делаем чтот не так. Может ктот совет дать?
о каких порядках речь? насколько большая разница? на сколько растёт время выполнения в зависимости от размера? что в explain(executionStats)?
madspectator
su -s /bin/bash mongodb или с любым другим удобным вам шеллом
Спасибо, заработала монга.
Evgeniy
о каких порядках речь? насколько большая разница? на сколько растёт время выполнения в зависимости от размера? что в explain(executionStats)?
В мускуле запрос выполняется 18 секунд. В монге почти 40
yopp
В мускуле запрос выполняется 18 секунд. В монге почти 40
18 и 40 это один порядок. в целом разница в два раза будет статистически незначимой и объясняется особенностями хранилищ
yopp
В первую очередь нужно смотреть на executionStats в explain
Evgeniy
18 и 40 это один порядок. в целом разница в два раза будет статистически незначимой и объясняется особенностями хранилищ
Хорошо.тогда по-другому .
Клиент строит отчёт. За месяц. В мускуле он проходит за 6 минуты. Монга его жует 13 ровно.
Evgeniy
При а при хайлоуде это вообще переходит в полную жо... 😒
Evgeniy
В первую очередь нужно смотреть на executionStats в explain
Хорошо. Ща гляну. . Как доберусь
yopp
Разница во времени не меняется, порядки одни и те-же. Вы фокусируетесь на абсолютных цифрах, но смотреть надо в первую очередь на относительные
yopp
Но нужно больше информации о том что вы храните, как вы это используете и как монга выполняет ваши запросы
Evgeniy
Понял.
Fask
всем привет. mongodb на ubuntu после ребута не запускается
madspectator
всем привет. mongodb на ubuntu после ребута не запускается
Смотрите, что напиcано в файле /var/log/mongodb/mongod.log
Fask
2020-01-20T16:48:05.221+0000 I CONTROL [main] ***** SERVER RESTARTED *****
2020-01-20T16:48:05.223+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] MongoDB starting : pid=3078 port=27017 dbpath=/var/lib/mongodb 64-bit host=xrmachine
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] db version v4.2.2
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] git version: a0bbbff6ada159e19298d37946ac8dc4b497eadf
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] allocator: tcmalloc
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] modules: none
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] build environment:
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] distmod: ubuntu1804
2020-01-20T16:48:05.234+0000 I CONTROL [initandlisten] distarch: x86_64
2020-01-20T16:48:05.235+0000 I CONTROL [initandlisten] target_arch: x86_64
2020-01-20T16:48:05.235+0000 I CONTROL [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "127.0.0.1", port: 27017 }, processManagement: { timeZoneInfo: "/usr/share/zoneinfo" }, storage: { dbPath: "/var/lib/mongodb", journal: { enabled: true } }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongod.log" } }
2020-01-20T16:48:05.237+0000 E STORAGE [initandlisten] Failed to set up listener: SocketException: Address already in use
2020-01-20T16:48:05.237+0000 I CONTROL [initandlisten] now exiting
2020-01-20T16:48:05.237+0000 I CONTROL [initandlisten] shutting down with code:48
fask@xrmachine:~$
madspectator
2020-01-20T16:48:05.237+0000 E STORAGE [initandlisten] Failed to set up listener: SocketException: Address already in use
madspectator
На порту 27017 висит кто-нить?
madspectator
netstat -lp | grep 27017 ?
Fask
только монго
Shamil | CS
lsof -i:27017
Fask
статус показывает failed
Fask
netstat -lp | grep 27017
tcp 0 0 localhost:27017 0.0.0.0:* LISTEN 3863/mongod
unix 2 [ ACC ] STREAM LISTENING 50961 3863/mongod /tmp/mongodb-27017.sock
Fask
это норма то что две строки выдает по команде?
Fask
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mongod 3863 mongodb 11u IPv4 50962 0t0 TCP localhost:27017 (LISTEN)
madspectator
А чего выдаёт pstree -aps 3863?
Fask
я не понял, но все заработало
Fask
спасибо))
Nikolay
Подскажите, в монге висят несколько простых запросов с растущим numYield, сервер по iops на пределе, по логам вижу портянку по типу
2020-01-20T14:53:32.494+0000 D STORAGE [conn27] WT begin_transaction for snapshot id 23408
2020-01-20T14:53:32.497+0000 D STORAGE [conn27] WT rollback_transaction for snapshot id 23408
id постоянно растет. куда смотреть?
Nikolay
я там и смотрю
yopp
А что тогда вас интересует? Скорее всего запросы читают большие объемы данных
yopp
Посмотрите на shape
Nikolay
там несколько запросов find с конкретным id, просто смущает что очень долго, и я не знаю, мог ли апгрейд с 3.6 на 4 так повлиять
Davudsho
Здраствуйте! Нужна помощь есть 2 схемы Category & Post. В схеме Post есть поле category_Id в котором хранится id категории к которому принадлежит данный пост, Мне нужно подсчитать кол. постов принадлежащей конкретной категорий, Стоит ли завести массив posts в схеме Category и что в ней хранить(cчетчик или _id поста) ?
yopp
там несколько запросов find с конкретным id, просто смущает что очень долго, и я не знаю, мог ли апгрейд с 3.6 на 4 так повлиять
Проверьте что запрос покрывается индексом
Nikolay
Проверьте что запрос покрывается индексом
Я вспомнил, что mongorestore делал без восстановления индексов, мне получается индексировать все коллекции надо?
yopp
Да
yopp
Здраствуйте! Нужна помощь есть 2 схемы Category & Post. В схеме Post есть поле category_Id в котором хранится id категории к которому принадлежит данный пост, Мне нужно подсчитать кол. постов принадлежащей конкретной категорий, Стоит ли завести массив posts в схеме Category и что в ней хранить(cчетчик или _id поста) ?
Проще всего начать с count по конкретному значению category_id, и сделать по этому полю индекс
Davudsho
Проще всего начать с count по конкретному значению category_id, и сделать по этому полю индекс
На главной странице мне нужны данные в таком формате
Davudsho
На главной странице мне нужны данные в таком формате
Category1 45, Category2 0, Category3 87 и тд.
yopp
В этом случае храните счётчик
Nick
Переиндексировал, пока все по прежнему
Используйте эксплейн и проверьте что индексы используются
Nikolay
Используйте эксплейн и проверьте что индексы используются
Да чёт странно, реиндекс сделал, а запрос индексами не покрывается и выполнялся 40 минут,
yopp
Да чёт странно, реиндекс сделал, а запрос индексами не покрывается и выполнялся 40 минут,
Если запрос был запущен до создания индексов, то он завершится по изначально выбранному плану
Nikolay
Я после пробовал, такой же результат. В общем повторный рестор со старыми индексами помог
yopp
Скорее всего или сигнатура индекса не совпадала или план запроса закешировался