yopp
/etc/mongodb.conf
yopp
там fork
yopp
читай доку
yopp
либо mongod --help
yopp
вроде можно аргументом форк выключить
J
блять зачем так сложно то
yopp
а ты откуда монгу ставил?
J
с реп
Sergey
С каких?
J
добавил офф монги
yopp
16 убунта в 3.2 поддерживается
yopp
проверь что у тебя там xenial/mongodb-org/3.2 multiverse
J
processManagement.fork should be false (which is also the default) in your mongod.conf file.
yopp
а не trusty/precise
J
но у меня в конфиге нет такого
yopp
можешь ещё попробовать руками сначала запустить
yopp
просто mongod и всё
J
типа mongod —config /etc/mongodb.conf ?
yopp
ну можно ещё конфиг указать, да
yopp
но если оно из пакетов, оно сконфигурировано с дефолтным конфигом в /etc
yopp
если оно пидорнётся, значит в монге проблема
yopp
если нет, в этом вашем systemd
yopp
но если 16 убунта заявлена как поддерживаемая, они должны были конфиги по-умолчанию поставлять уже заточенные под systemd
J
mongod —config /etc/mongodb.conf
Error parsing YAML config file: yaml-cpp: error at line 8, column 9: illegal map value
J
там у меня
J
#where to log
logpath=/var/log/mongodb/mongodb.log
engine: mmapv1
logappend=true
yopp
ты определись
yopp
либо у тебя yaml
yopp
либо у тебя старый key=value формат
yopp
у тебя щас говно а не конфиг
J
смотри я просто раскоментил строки в конфиге
yopp
я не знаю что ты где раскоментил, но у тебя сейчас там и yaml и k=v
yopp
и оно ругается что оно не может распарсить лог
yopp
открой доку и конвертни конфиг в yaml
yopp
и запусти снова
J
ок спс ща гляну
J
mongod —config /etc/mongodb.conf
J
запускается
J
а если через инит скрипт нет
J
была ошибка в конфиге
J
поправил
J
руками запускатеся
J
почему не запускается инитскриптом или через сервис ?
Roman
@lig11 а у гошного драйвера монги нет такой беды со скоростью как у питона?
Roman
Я вообще думаю заменить монгу на тарантул :)
Sergey
bson кодер в pymongo сишный и достаточно шустрый
Sergey
Для каких задач?
Sergey
с gridfs не работал
Sergey
хотя, идея писать в базу блобы сама по себе не очень хорошая
Sergey
на мелких данных все больше в сеть упирается
Roman
А что такого? :)
Sergey
да просто зачеи тогда вообще монга, если не нужно ни реплик, ни шардинга
Sergey
ну python никогда не был эталоном скорости, но какие варианты? писать на C?
Roman
да просто зачеи тогда вообще монга, если не нужно ни реплик, ни шардинга
Например, у меня несколько шардов по миру
Sergey
пока вы пишете, конкуренты уже запустят проект и он умрет своей смертю =)
Roman
ну python никогда не был эталоном скорости, но какие варианты? писать на C?
Ну, есть pypy. Но если формат дурацкий, то даже сишечка не спасет
Roman
Я общаюсь с монгой через сокет.
Roman
Я ее понимаю вопроса
Roman
Например? Я на pypy бенчил питоновский struct. Вообщем, на си получилось всего в 2 раза быстрее
Sergey
Например? Я на pypy бенчил питоновский struct. Вообщем, на си получилось всего в 2 раза быстрее
у pypy свои недостатки, например, он до сих пор только 3.2 умеет
J
ребят разобрался с монгой, дело было в системд
J
у меня 2 вопроса почему нет инит скрипта для 3.2
J
и почему нет комманды service mongod restart
J
тоесть терь все манипуляции с стартом и рестартом только через него?
Sergey
там есть пачка костылей, но все в конечном итоге дергает systemctl
Sergey
через него же завернуты и legacy init-скрипты, причем порой криво
Stanislav
Можно ли из монги сделать очередь с exactly-once доставкой, которая будет держать хотя бы 5к рпс на одной машинке?
1) Я пробовал findAndModify, но он медленный очень.
2) Я еще пробовал вот так:
while (true) {
db.queue.update( {"status": "new"}, {"status": "pending_on_<consumer_id>"} ) //уникальность consumer_id гарантируется самими потребителями
def messages = db.find( {"status": "pending_on_<consumer_id>"} )
doWork(messages)
db.update( {$in: messages.*_id}, {"status": "done"} )
}
но с этим подходом проблема в том, что в update нет limit'а. И получается, что каждый потребитель забирает себе тупо все сообщения и будет их должго обрабатывать, вместо того, чтобы расперделитьь эти сообщения на всех потребителей
есть идеи?
Alex
Можно ли из монги сделать очередь с exactly-once доставкой, которая будет держать хотя бы 5к рпс на одной машинке?
1) Я пробовал findAndModify, но он медленный очень.
2) Я еще пробовал вот так:
while (true) {
db.queue.update( {"status": "new"}, {"status": "pending_on_<consumer_id>"} ) //уникальность consumer_id гарантируется самими потребителями
def messages = db.find( {"status": "pending_on_<consumer_id>"} )
doWork(messages)
db.update( {$in: messages.*_id}, {"status": "done"} )
}
но с этим подходом проблема в том, что в update нет limit'а. И получается, что каждый потребитель забирает себе тупо все сообщения и будет их должго обрабатывать, вместо того, чтобы расперделитьь эти сообщения на всех потребителей
есть идеи?
Не уверен что точно подразумевается под exactly-once, но у нас на findAndModify решена задача, когда из кучи документов нужно по определенным критериям сортировки воркер забирает себе (update) 1 документ. Машины разные бывают,у нас штатно 1000-1500 rps. Просто с fAM нужно тщательно индексы подготовить, посмотреть, чтобы он их использовал.
Alex
(м, немного несогласованное предложение, сорри, болею)
yopp
Можно ли из монги сделать очередь с exactly-once доставкой, которая будет держать хотя бы 5к рпс на одной машинке?
1) Я пробовал findAndModify, но он медленный очень.
2) Я еще пробовал вот так:
while (true) {
db.queue.update( {"status": "new"}, {"status": "pending_on_<consumer_id>"} ) //уникальность consumer_id гарантируется самими потребителями
def messages = db.find( {"status": "pending_on_<consumer_id>"} )
doWork(messages)
db.update( {$in: messages.*_id}, {"status": "done"} )
}
но с этим подходом проблема в том, что в update нет limit'а. И получается, что каждый потребитель забирает себе тупо все сообщения и будет их должго обрабатывать, вместо того, чтобы расперделитьь эти сообщения на всех потребителей
есть идеи?
http://tugdualgrall.blogspot.fr/2015/01/how-to-create-pubsub-application-with.html
но я не уверен что можно организовать exactly-once
yopp
но если роутинг на уровне приложения обеспечен, то почему бы и нет
yopp
тоесть мы кидаем в capped сообщение адресованное конкретному подписчику, в этом случае проблем быть не должно
Stanislav
Не уверен что точно подразумевается под exactly-once, но у нас на findAndModify решена задача, когда из кучи документов нужно по определенным критериям сортировки воркер забирает себе (update) 1 документ. Машины разные бывают,у нас штатно 1000-1500 rps. Просто с fAM нужно тщательно индексы подготовить, посмотреть, чтобы он их использовал.
А у вас коллекция большая? И на каких машинках морга бежит?
Stanislav
но если роутинг на уровне приложения обеспечен, то почему бы и нет
Не, хочется без роутинга на стороне приложений. Тогда-то уже проще будет кролика прикрутить сбоку