I have a big table in a data base which is updated almost every second. I want to query this table every 5 second to get the latest entries (live streaming).
I can't query data base for each visitor (ajax post request every 5 seconds) because mysql will die. This is why I need to cache a file. I'm writing data in a file than a visitor with javascript will open/read/close the file every 5 second.
Everything works fine, but I'm having trouble with cronjob + sleep.
In cpanel I can't set 5 sec cronjobs, this is why I'm running a for() with 12 cycles within 5 sec sleep.
for($i = 0; $i <12; $i++){
mysql_query() /// writing in file, etc.
sleep(5);
}
The problem is this is freezing out the entire server for 60 seconds. Not only the cronjob php file, the entire web page is timed out.
What should I do? Am I doing it right?
Note there is no guarantee that the code you posted is going to run in precisely 60 seconds. In fact, that code is going to run in AT LEAST 60 seconds. I'm not sure if that matters, but this means there's going to be a period of overlap between two or more instances of this script running via cron.
Depending on your queries and the way you're handling your database and cache reads/writes, you could be creating a database lock or deadlock situation, which in turn could cause the script to run long. Running long means it's potentially eating up database/server resources. This situation is what I'm leaning towards as the cause for your web page timeout. I'd need more details regarding your queries and database/cache file.
Related
I need to fetch the values of about 200 sensors every 15 seconds or so. To fetch the values I simply need to make an HTTP call with basic authentication and parse the response. The catch is that these sensors might be on slow connection so I need to wait at least 5 seconds for one sensor (but usually they respond a lot quicker, but there's always some that are slow and timeout).
So right now I have the following setup for that:
There is a NodeJS process that is connected to my DB and knows all about the sensors. It checks regularly to see if there are new ones or there are some that got deleted. It spawns a child process for every sensor, and in case the child process dies it restarts it. Also it kills it if the sensor gets deleted. The child process makes the HTTP call to its sensor with a 5 second timeout value and if it receives the value, saves it to Redis. Also it is in an infinite loop with a 15 seconds setTimeout. And there is a third process that copies all the values from Redis to the main MySQL DB.
So that has been a working solution for half a year, but after a major system upgrade (from Ubuntu 14.04 to 18.04 and thus every package upgraded as well) it seems to leak some memory and I can't seem to figure out where.
After starting out, the processes summarised take about 1.5GB of memory. But after a day or so this goes up to 3GB and so on and before running out of memory I need to kill all node processes and restart the whole thing.
So now I am trying to figure out more efficient methods to achieve the same result (query around 2-300 URLs every 15 sec and store the result in MySQL). At the moment I'm thinking of ditching Redis and the child processes will communicate with their master process and the master process will write to MySQL directly. This way I don't need to load the Redis library into every child process and that might save me some time.
So I need ideas on how to reduce memory usage for that application (I'm limited to PHP and NodeJS, mainly because of my knowledge, so writing a native daemon might be out of the question)
Thanks!
The solution was easier than I thought. I had to rewrite the child process into a native bash script and that brought down the memory usage to almost being zero.
Solved : It's a node bug. Happens after ~25 days (2^32 milliseconds), See answer for details.
Is there a maximum number of iterations of this cycle?
function do_every_x_seconds() {
//Do some basic things to get x
setTimeout( do_every_x_seconds, 1000 * x );
};
As I understand, this is considered a "best practice" way of getting things to run periodically, so I very much doubt it.
I'm running an express server on Ubuntu with a number of timeout loops .
One loop that runs every second and basically prints the timestamp.
One that calls an external http request every 5 seconds
and one that runs every X 30 to 300 seconds.
It all seemes to work well enough. However after 25 days without any usage, and several million iterations later, the node instance is still up, but all three of the setTimout loops have stopped. No error messages are reported at all.
Even stranger is that the Express server is still up, and I can load http sites which prints to the same console as where the periodic timestamp was being printed.
I'm not sure if its related, but I also run nodejs with the --expose-gc flag and perform periodic garbage collection and to monitor that memory is in acceptable ranges.
It is a development server, so I have left the instance up in case there is some advice on what I can do to look further into the issue.
Could it be that somehow the event-loop dropped all it's timers?
I have a similar problem with setInterval().
I think it may be caused by the following bug in Node.js, which seem to have been fixed recently: setInterval callback function unexpected halt #22149
Update: it seems the fix has been released in Node.js 10.9.0.
I think the problem is that you are relying on setTimeout to be active over days. setTimeout is great for periodic running of functions, but I don't think you should trust it over extended time periods. Consider this question: can setInterval drift over time? and one of its linked issues: setInterval interval includes duration of callback #7346.
If you need to have things happen intermittently at particular times, a better way to attack this would be to schedule cron tasks that perform the tasks instead. They are more resilient and failures are recorded at a system level in the journal rather than from within the node process.
A good related answer/question is Node.js setTimeout for 24 hours - any caveats? which mentions using the npm package cron to do task scheduling.
It goes like this: in my test method, I have 3 Playback.Wait() calls. Each one is set to 2 minutes. Between those waits, I am doing some stuff here and there, - that stuff works, was tested without those 3 waits and is all OK. As soon as 3 waits are there, test method just exists on its own, somewhere during 2nd wait. There is no call stack, no useful info regarding the cause for test termination, nothing. I am pretty much clueless at the moment what is happening. Elapsed time is always 5 minutes, - no more no less.
Do you have any idea what can be wrong?
This is a setting in your .testsettings file, under Test Timeouts section. Specifically, "Mark individual test as failed if its execution time exceeds:", and then gives you fields to enter time in hours, minutes, and seconds. I believe that 5 minutes is the default. You can increase this to fit your purpose, or just remove it entirely (not reccommended).
I am building an open sourced nodejs powered sprinkler system which will run on the raspberry pi and work with the OpenSprinkler Pi.
I am using:
sailsjs 0.9.3
laterjs - for schedule interpretation and maths
i created an issue awhile back on bunkats repo asking for him to explain this to me.. https://github.com/bunkat/later/issues/19
The end result will be a REST api interface between rpi and whatever front-end you decide to develop for. web/mobile/cli .. etc.
The way the scheduling component will work is values will be posted to the url /programs with a zone id, name, intial status (false), and a plain text human readable schedule phrase such as: every 12 hours starting on the 6th hour before 10 minutes (06:00 & 18:00 for 10 mins).
This schedule will be parsed, and stringified and stored in db as such:
{\"schedules\":[{\"h\":[6,18],\"m_b\":[10]}],\"exceptions\":[],\"error\":-1}
The other values are cleaned and stored as they were entered.
My question is:
how should I go about finding these schedules and determining their run time/date? I've got the scheduling part, and the run time down and working (run for 10 mins). I'm struggling with the theory behind efficiently retrieving the schedules though.
My initial thought was to have a interval every 1 mins poll the db...
setInterval(function(){
//get programs from db
//iterate through programs
//enable programs which start now?
}, 60000);
But this seems kind of illogical. I suppose that when the schedule is created a setInterval or setTimeout is created with the appropriate scheduling info.. but what happens if the rpi loses power, or those could eat up a bit of memory having all of these intervals hanging out there..
how will it handle existing schedules already in the db?
open source repo
of what i have so far (not much other than the creation api/models/Programs.js) is here:
https://github.com/RelativeMedia/nodesprinkler.git
Running a single script with only two users as a single scenario without any pacing, just think time set to 3 seconds and random (50%-150%) I experience that the web app server runs of of memory after 10 minutes every time (I have run the test several times, and it happens at the same time every time).
First I thouhgt this was a memory leak in the application, but after some thought I figured it might have to do with the scenario design.
The entire script having just one action including log in and log out within the only action block takes about 50 seconds to run and I have the default as soon as the previous iteration ends set not the with delay after the previous iteration ends or fixed/random intervalls set.
Could not using fixed/random intervalls cause this "memory leak" to happen? I guess non of the settings mentioned would actually start a new iteration before the one before ends, this obvioulsy leading to accumulation of memory on the server resulting in this "memory leak". But with no pacing set is there a risk for this to happen?
And having no iterations in my script, could I still be using pacing?
To answer your last question: NO.
Pacing is explicitly used when a new iteration starts. The iteration start is delayed according to pacing settings.
Speculation/Conclusions:
If the web-server really runs out of memory after 10 minutes, and you only have 2 vu's, you have a problem on the web-server side. One could manually achieve this 2vu load and crash the web-server. The pacing in the scripts, or manual user speeds are irrelevant. If the web-server can be crashed from remote, it has bugs that need fixing.
Suggestion:
Try running the scenario with 4 users. Do you get OUT OF MEMORY on the web-server after 5 mins?
If there really is a leak, your script/scenario shouldn't be causing it, but I would think that you could potentially cause it to appear to be a problem sooner depending on how you run it.
For example, let's say with 5 users and reasonable pacing and think times, the server doesn't die for 16 hours. But with 50 users it dies in 2 hours. You haven't caused the problem, just exposed it sooner.
i hope its web server problem.pacing is nothing but a time gap in between iterations,it's not effect actions or transactions in your script