It's informative for what happens in the web interface.
That's great(er than expected, meaning lot's of good info)The memory usage shown there is for the entire request
For console (send-campaigns, bounce processing, etc etc) we keep track at /backend/index.php/misc/cron-jobs-history where we can see a short history for each command/cron job that ran
I think that's just how long it took, 0.02 is fine for a cron job that did nothing.
For PCNTL it only shows for the master process, not for children as it's impossible. You can do some math and multiply with the number of processes.
Sure, and/but, if there was no file to process...the cron history for import will show an "error", correct?
Of course
Just wondering, that this would be quite low (4.5MB x 50proc = 225MB), but sending takes quite a bit memory (stats table says ca 1GB more than when not sending), so it must be elsewhere as well (not just in the processes). What/where do you think this is?
Nope, that's not an error. An error is when the cron fails to run and/or finish
Well, when pcntl is enabled measuring memory usage plays tricks. I think the best way to measure it in that case is to run it without pcntl.
Tested it, so after update, before first import by cron, the cron history will said "error" when there was no file uploaded, but after testing it, it shows success, also for all empty/no file future import crons.Nope, that's not an error. An error is when the cron fails to run and/or finish
The stats mentioned above, compare total server memory usage before any send starts (when no camp/pcntl sends), to when sending is at max (ie camp sending w/50 proc). These totals are from cli sar, so I guess they are absolute, i.e. sar does not care what runs, it just logs resources consumed.
