Out of Memory crashes

[nbhead]

Hi,

I am nowadays receiving quite a lot of "Out of memory" crashes and was wondering if you can take a look at it.

Logs send: 94242

As for the memory issues, here are my VPS details:

OS: Windows Server 2008 r2 x64
CPU: 2 vCore
RAM: 8GB

However I do run some other programs on it 24/7 as well, but none of them are receiving errors and from my manually checking the memory usages, it doesn't go above 30%

The other outcome of those out of memory crashes is that the previous actions/processes or how you call them, are messed up and some are now multiplied by 12. See below screenshot.

[nbhead]

Want to add somethings.

As stated above, restarting the program after the out of memory crashes, causes many processes/actions to multiply. This is solved by manually deleting the processes/actions, which is a bit of a pain, but doesn't take too much time.

However, the process/action of posting pictures does NOT get multiplied, but after restarting it just continuesly keeps on posting and posting and posting images. It does not adhere to the specified maximum number of posts anymore. For example I have set my posting to 1 +/- 2 per hour. The program crashed 13 hours ago. On average the program should have posted 2 x 13 = 26 posts, however after posting 38 pictures/posts in one run it still didn't stop and I therefore had to cancel it manually.

This is a real problem as the only solution to this is to manually delete everything and then start entirely from scratch, meaning that I have to setup every single campaign with new Meta's and everything. This really gets annoying after a few days out of memory crashes, especially since the most labour intensive settings are not saved inside the program.

[TheNightloser]

I have the same issue with "out of memory" since I've been using this bot. From what i'm seeing you are running a lot of threads on the bot(i'm running maximum 20-30 threads and occasionally get this problem). From my experience if the tumblr jazz process is reaching 1.5 GB of RAM it will start sending out of memory errors and then if you are adding more threads or you begin fiddling with threads detail the bot will crash. In my opinion TumblrJazz doesn't manage memory properly and has some limitations being a 32 bit program. If Martin will decide to write a 64 bit version things will get a lot better(imo) but...

Anyway a solution to this problem is splitting tasks between multiple instances of the bot(runing several customDB's), and don't fiddle much with the threads, leave them as they are, don't click on details...

[martin@rootjazz]

Out of memory issue:

http://rootjazz.com/tumblingjazz/updatetesting.html

Then when app loads
HELP > CONFIG > do not cache

restart the app

Hopefully that should help

Want to add somethings.

As stated above, restarting the program after the out of memory crashes, causes many processes/actions to multiply. This is solved by manually deleting the processes/actions, which is a bit of a pain, but doesn't take too much time.

Is it just the likes that multiply? Or other types of actions?

Your like returns, are just simple, search and like actions? Any particular settings?
Do the repeats happen every app reload?

However, the process/action of posting pictures does NOT get multiplied, but after restarting it just continuesly keeps on posting and posting and posting images. It does not adhere to the specified maximum number of posts anymore. For example I have set my posting to 1 +/- 2 per hour. The program crashed 13 hours ago. On average the program should have posted 2 x 13 = 26 posts, however after posting 38 pictures/posts in one run it still didn't stop and I therefore had to cancel it manually.

Will check the persistence of existing actions on a reload and get back to you

[martin@rootjazz]

POst image action. Specify to post 1 image
Restart app, re run action - posts 1 image.

So for me it seems to persist.


Maybe the issue is related somehow to your duplication errors in the processing tab (also not happening here)

submit your logs
HELP > LOGS > SUBMIT

then send your logs ID - the first 4 numbers is sufficient (displayed after successful uploading of logs)


maybe there is something there, if not will add more debugging code



Regards,
Martin

[nbhead]

Thanks for looking into it.

I had already send you the log files as also stated in my opening post, Logs send: 94242

The actions persist after normal restarting, yes, but restarting after the out of memory crash, they do not always persist. For some they do, for some they don't. For some even the number of images that are to be posted in total changed for some inexplicable reason, ie from the normal 15000 images that are in the folder to 3600 images or 1600.

I am also pretty sure that I deleted all post image actions, but I just found one account that reached the daily limit, which seems to be around 150 images or so while the day is still early and normally it should not have posted more than 20. Not 100% sure about the delete part, but 99.99999%.

It affects all actions and all actions are very simple search and like, nothing fancy.

The repeats only happen after out of memory crashes, not after normal restarting.

I am actually not running a lot of threads, all individual settings are 1 thread and for the entire program I change it sometimes, but never more than 8. Which btw also doesn't seem to work properly as even with 8 threads specified only 3 or 4 processes are actually processing at the time and even when I click on "run next" it doesn't open a new thread, while not all 8 threads are busy.

[nbhead]

Hmm, just updated to the test version...

The old version was working properly before I shut it down and installed the new test version, selected do not cache and restarted again. After starting the new test version, there are again multiple instances of all actions and this I do know for 100% sure that I also deleted the post images, but somehow they are back and again the number of images to be posted changed as well.

So basically all the multiple and wrong instances that I deleted earlier, are back with the no cache restarted new version.

Is perhaps my entire database screwed up?

[nbhead]

It seems that data doesn't always get written to or deleted from the database.

A few hours ago I created some extra actions, and now some of them are gone and I have to re-enter them. Some of them, not all.

A few hours ago I deleted many instances, and now they were all back + another 80 in total and I had to re-delete them again.

[nbhead]

Version 1.4.27 crashed again with the same problems as before, just updated to 1.4.30 and unfortunately some problems still exist.

I hope/think I now only have problems with posting images after the crash, but since it has been a very short time, I cannot be sure what surprises come next.

What I am sure of, is that again the process just keeps on posting and posting and posting images and doesn't adhere to the specified 1 +/- 2 per hour. And also again the total number of images to be posted changed drastically.

As said before, the number of pictures to be posted should be 15,000 or so, but now they are between 400 and 10,000.

I really hope it will be fixed soon...

[martin@rootjazz]

Please try the latest update, hopefully that fixes some of your issues (just put out this morning)

http://rootjazz.com/tumblingjazz/updatetesting.html