4 ms·

> Or you can process memory dumps of a machine larger than yours. You should be able to that in software anyways - instead of loading to memory entirely, all i

by xxs 6y ago

> Or you can process memory dumps of a machine larger than yours. You should be able to that in software anyways - instead of loading to memory entirely, all it has to do is memory map the file dump. About the need to freeze a process (group). I don't quite see how that's useful on a server. On a desktop machine I have never run into such a case where closing the application would not suffice. Is there an example? Last - using the swap pretty much means no disk cache.

the8472 6y ago
> You should be able to that in software anyways - instead of loading to memory entirely, all it has to do is memory map the file dump. Should, perhaps. But in practice I have had analyzers gobble up more memory than available. > About the need to freeze a process (group). I don't quite see how that's useful on a server. On a desktop machine I have never run into such a case where closing the application would not suffice. Is there an example? Long-running renderjob, preempted by a higher-priority one. Technically they're resumable so we could stop them and resume the other one later from a snapshot file but that isn't implemented in the current workers. So as long as the machine has enough ram+swap it's easier to freeze the current job and start the higher-priority one. > Last - using the swap pretty much means no disk cache. I don't know all the tunables of the swap subsystem well enough but I have seen swap being used before running out of physical ram. I assume some IO displaced inactive applications.
- xxs 6y ago
  >analyzers gobble up more memory than available. I can run 128GB, if need be. But yeah if the software is pitiful and poorly implemented. Running on swap is an one-time-option I guess. >so we could stop them and resume the other one later from a snapshot file but that isn't implemented in the current workers. Indeed, this seems like a poor implementation, lacking 'save' function. I have not run into similar cases.

by xxs 6y ago

the8472 6y ago

> You should be able to that in software anyways - instead of loading to memory entirely, all it has to do is memory map the file dump. Should, perhaps. But in practice I have had analyzers gobble up more memory than available. > About the need to freeze a process (group). I don't quite see how that's useful on a server. On a desktop machine I have never run into such a case where closing the application would not suffice. Is there an example? Long-running renderjob, preempted by a higher-priority one. Technically they're resumable so we could stop them and resume the other one later from a snapshot file but that isn't implemented in the current workers. So as long as the machine has enough ram+swap it's easier to freeze the current job and start the higher-priority one. > Last - using the swap pretty much means no disk cache. I don't know all the tunables of the swap subsystem well enough but I have seen swap being used before running out of physical ram. I assume some IO displaced inactive applications.

xxs 6y ago
>analyzers gobble up more memory than available. I can run 128GB, if need be. But yeah if the software is pitiful and poorly implemented. Running on swap is an one-time-option I guess. >so we could stop them and resume the other one later from a snapshot file but that isn't implemented in the current workers. Indeed, this seems like a poor implementation, lacking 'save' function. I have not run into similar cases.