3 ms·

Visualizing All Processes in a Datacenter

31 points by kixpanganiban 9y ago

lathiat 9y ago
I feel like having cron, by default, lock out the next iteration of a program or at least some kind of spawn limit would be ideal. I see this a LOT with wordpress & PHP "developers" deployed on shared hosting (where they often don't observe the runtime and such of these things). They end up having one script step over the next and the next and eventually combined they are generating so much load on the database or some other service that none of them ever finish. Fun fun... I wonder if systemd timers can do that?
- lathiat 9y ago
  Seems like this is actually the default behaviour for a systemd timer, ha. "Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running." On the flip side I wonder if you can tell it to timeout and kill the service after a while, as I can equally see them getting stuck and never running again, a problem you don't have with the alternative method :-) Ah, choices...
  - rakoo 9y ago
    Right in the doc (https://www.freedesktop.org/software/systemd/man/systemd.unit.html# https://www.freedesktop.org/software/systemd/man/systemd.uni...): > JobTimeoutSec=, JobRunningTimeoutSec=, JobTimeoutAction=, JobTimeoutRebootArgument= > When a job for this unit is queued, a time-out JobTimeoutSec= may be configured. Similarly, JobRunningTimeoutSec= starts counting when the queued job is actually started. If either time limit is reached, the job will be cancelled
- smueller1234 9y ago
  It's also a fairly trivial thing to implement with flee system locks (just make sure your fs had sane semantics). In fact, with a bit of cleverness and fs locks you can implement more complex patterns trivially as well such as a pseudo daemon that is both cycled (without appreciable downtime) regularly as well as having a backup process to take over on failure. Obviously, you don't run your webserver that way (right!?) but it's not nuts to manage (even near real-time) queue consumers in a backend that way.
graysonk 9y ago
From 2014

31 points by kixpanganiban 9y ago

I feel like having cron, by default, lock out the next iteration of a program or at least some kind of spawn limit would be ideal. I see this a LOT with wordpress & PHP "developers" deployed on shared hosting (where they often don't observe the runtime and such of these things). They end up having one script step over the next and the next and eventually combined they are generating so much load on the database or some other service that none of them ever finish. Fun fun... I wonder if systemd timers can do that?

lathiat 9y ago
Seems like this is actually the default behaviour for a systemd timer, ha. "Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running." On the flip side I wonder if you can tell it to timeout and kill the service after a while, as I can equally see them getting stuck and never running again, a problem you don't have with the alternative method :-) Ah, choices...
- rakoo 9y ago
  Right in the doc (https://www.freedesktop.org/software/systemd/man/systemd.unit.html# https://www.freedesktop.org/software/systemd/man/systemd.uni...): > JobTimeoutSec=, JobRunningTimeoutSec=, JobTimeoutAction=, JobTimeoutRebootArgument= > When a job for this unit is queued, a time-out JobTimeoutSec= may be configured. Similarly, JobRunningTimeoutSec= starts counting when the queued job is actually started. If either time limit is reached, the job will be cancelled
smueller1234 9y ago
It's also a fairly trivial thing to implement with flee system locks (just make sure your fs had sane semantics). In fact, with a bit of cleverness and fs locks you can implement more complex patterns trivially as well such as a pseudo daemon that is both cycled (without appreciable downtime) regularly as well as having a backup process to take over on failure. Obviously, you don't run your webserver that way (right!?) but it's not nuts to manage (even near real-time) queue consumers in a backend that way.

graysonk 9y ago

From 2014