Operational statistics should be accessible in order to check / debug proper working conditions and possibly memory leaks:
- Session Count
- Statement Count
- Allocated Buffer Sizes
- Last Session Activity TS
Ideally, we would be able to dump internal state snapshot when needed and analyze it offline (in some open source analyzer tool or self-woven erlang tool).
If this is too difficult, compiling for debug and starting a pool or single driver in debug mode should at least be possible.
Comments so far:
Native programs like ocierl.exe or erlang VM (erl.exe) doesn’t let inspection for memory leakage or reading of any other internal process state info from outside. So at the moment we can’t debug ocierl.exe for memory leak.
However we can start ocierl.exe differently (compiled with debug) with some Microsoft memory analyzer tool (like http://valgrind.org/ in linux) and try to make it work and interpret the data. Not sure what is available and will work for erloci – requires some trial and error.
If not, please consider creating one which gives insight into the resource consumption per session and statement (together with last access timestamp if possible).
One lead to this direction would be https://msdn.microsoft.com/en-us/library/x98tx3cf.aspx a good approach to detect memory leaks. I am not sure however it can be per OCI session/statement (not even sure I can be per thread). I can’t confirm what will be possible until I try different options.
Operational statistics should be accessible in order to check / debug proper working conditions and possibly memory leaks:
Ideally, we would be able to dump internal state snapshot when needed and analyze it offline (in some open source analyzer tool or self-woven erlang tool).
If this is too difficult, compiling for debug and starting a pool or single driver in debug mode should at least be possible.
Comments so far:
Native programs like ocierl.exe or erlang VM (erl.exe) doesn’t let inspection for memory leakage or reading of any other internal process state info from outside. So at the moment we can’t debug ocierl.exe for memory leak.
However we can start ocierl.exe differently (compiled with debug) with some Microsoft memory analyzer tool (like http://valgrind.org/ in linux) and try to make it work and interpret the data. Not sure what is available and will work for erloci – requires some trial and error.
If not, please consider creating one which gives insight into the resource consumption per session and statement (together with last access timestamp if possible).
One lead to this direction would be https://msdn.microsoft.com/en-us/library/x98tx3cf.aspx a good approach to detect memory leaks. I am not sure however it can be per OCI session/statement (not even sure I can be per thread). I can’t confirm what will be possible until I try different options.