AWS Thinkbox Discussion Forums

Database corruption v2

OK I think I spotted something

The jobs starting with the _id attribute are always the one locking deadline Pulse into a loop (also affects deadlinecommand CleanupJobs command)

The only other difference is that this job also doesn’t have a “LastWriteTime” Attribute, which is why it’s crashed I suppose

Hope this helps

If your db master has a command that would allow me to quickly remove from mongodb these stucked jobs I’d really appreciate

Thanks

That should definitely be helpful. We’ll see if we can reproduce here. At the very least, a missing last write time shouldn’t result in a crash, so we’ll have to figure out why this is the case.

Thanks!

  • Ryan

More information :
happens mainly on very short jobs, with autodelete only

example with 2 very similar jobs :

The one wich is locking pulse into infinite loop

The one which is fine and will autodelete soon

Can you post the Pulse log when it’s in an infinite loop? We’re starting to dig into this issue now, and the more information we have, the better!

Thanks!

  • Ryan

Pulse repeating

Sorry Pulse verbose logging wasn’t enabled

I think I can reproduce it easily but these jobs are urgent,
so we disabled auto-delete for now, I’ll try to test it with verbose mode as soon as possible

Thanks! In beta 10, we will be making a change that makes it impossible for a job to ever exist without a LastWriteTime property (unless of course someone manually removes that property directly from the database). So any new jobs submitted after upgrading to beta 10 will always have this property set, even if it’s just the default value.

In theory, this should fix the problem you are seeing with Pulse.

Cheers,

  • Ryan

Thanks

I can confirm this happens with auto-delete jobs only,

more than 12 000 jobs were running this night without any trouble

at least we’re testing the new database styled Deadline heavily, and it is way more responsive than the previous approach
congrats guys

The more we have the best we fix so here we go
An autodelete job appeared from a forgotten manual submit script

I catched the log from Pulse verbosed, luckily it did not stay in infinite loop, but there’s definitely something weird happening

See attached for the log

I also tried db.Jobs.find( { “LastWriteTime” : { $exists : false } } ) on the mongo db but it did not return any result
database-log.txt (10.2 KB)

Good to know. Just an FYI that beta 10 should be released later today, and will include the fix that ensures jobs created by beta 10 or later will always have that property defined.

That’s awesome! We’re really glad to hear it’s working well for you and that you notice the improvements! :slight_smile:

Alcium I would be intrigued to know how much disk space and RAM your Mongo-DB isusing. I think you’ve probably created a stress test on the outer-bounds of what we’ll ever see in our queue so a little real-world insight would be great if you could share!

I did not notice any particular usage, this was really in capability of the server

We have an HP Proliant DL 360 G6 With 1x Xeon E5520 @ 2.27GHz CPU / 6 GB RAM
The Deadline Repository is on a SSD drive (which was the best solution for sharing the dozens of files for pre-6.0 version)

Really nothing went high in the Deadline system I think the db was about 1GB

this works really well as long as pulse is not going crazy with weird corrupted jobs

Privacy | Site terms | Cookie preferences