267 reputation
38
bio website
location
age
visits member for 2 years, 2 months
seen Aug 15 at 11:42

Aug
15
comment mongodb: maxTimeMS ignored
checking the stats in aggregation proves that in general timeout works, but though, we have some delayed or locked queries, using the same index, but the system hanging worse. the index is half size of available RAM, dedicated hardware server and RAID10 disk. about 200 insert/update and about 1300 findOne (on single field index) per second. most of these requests are processed without any delay, average time for read is 30ms, but for unknown there are hanging queries, taking up to 500ms and delaying all the application and other queries. still suffering on that behaviour issue.
Aug
15
accepted mongodb: maxTimeMS ignored
Aug
14
revised mongodb: maxTimeMS ignored
deleted 18 characters in body
Aug
13
asked mongodb: maxTimeMS ignored
Jul
2
awarded  Curious
May
21
awarded  Notable Question
May
6
awarded  Notable Question
Nov
7
awarded  Yearling
Jul
23
asked Check and remove iteratively without an index
Jul
19
awarded  Popular Question
Jul
15
accepted mongostat causing CPU 100%
Jul
12
asked mongostat causing CPU 100%
Jul
12
comment Locking and Faulting on import
added OS, MongoDB version. Furthermore, upgraded RAM to 48GB. without improvemenent.
Jul
12
awarded  Editor
Jul
12
revised Locking and Faulting on import
added 43 characters in body
Jul
11
asked Locking and Faulting on import
Jun
19
comment MongoDB fast upsert
so mongoimport is using the fastest import method already, scanning _id index "only"? Anyways, it's locking the db as soon as i start mongoimport: nopaste.info/d4d8009b5a.html The RAM is 50% only and the index is checked/OK. Can't find the mistake or reason for locking.
Jun
19
comment MongoDB fast upsert
mongoimport -d ... -c ... --upsert < .../path.json
Jun
18
asked MongoDB fast upsert
May
27
comment MongoDB: move documents before capping
first approach sounds good, but seems to lock the db when new INSERTs arrive at the same time as the cleaning script is active. Regarding the index after removing mass of data, is not damaged but is growing and growing without exhausting reIndex process which requires maintenance because of locks, too. The other 2 approaches seem to be a bit overkill, don't they?