You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A little while ago I mentioned in #znc about a memory leak problem I was experiencing. What was happening was that I'd start up ZNC (1.6), and about two weeks later, I'd be at my servers comfortable memory limit (gone up from 50% -> 93%) after steadily rising during its running.
I upgraded from ZNC 1.4 on the same server, which didn't have this issue at all. The only difference between the two version is that I "upgraded" from znc-push's C branch to the actively developed Python branch. This meant I needed to also compile ZNC 1.6 with modpython (which I didn't have previously). This, on one hand, makes me suspect either modpython or push as the responsible parties. However, doing a /msg *status unloadmod push; /msg *status unloadmod modpython does not reduce memory usage at all.
Having said that, I haven't tried starting ZNC with both of these disabled - only unloading them and reloading them (as two separate tests). Aside from these, the only other modules I use are "core" modules. I can provide a breakdown if need be.
As for memory usage profiling, I've run ZNC under massif for the last few days, and each of the different functions do not grow (significantly) in usage over time, except one. The details of which are listed below:
The text of the largest snapshot, nested, are as follows:
0x593F207: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x594092F: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x59409EB: std::basic_string<char, std::char_traits<char>, std::allocator<char>>::basic_string(char const*, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
0x8774845: SWIG_AsPtr_std_string(_object*, CString**) (in /usr/local/lib/znc/modpython/_znc_core.so)
0x87F51B5: _wrap_CIRCNetwork_ExpandString (in /usr/local/lib/znc/modpython/_znc_core.so)
0x784A201: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7973514: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x784A56B: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x784C943: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7973B44: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7888456: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x78B181B: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7888456: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x7868ADF: PyObject_CallMethodObjArgs (in /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0)
0x75227FB: CPyModule::OnChanMsg(CNick&, CChan&, CString&) (in /usr/local/lib/znc/modpython.so)
0x4BBADE: CModules::OnChanMsg(CNick&, CChan&, CString&) (in /usr/local/bin/znc)
0x47EDA8: CIRCSock::OnChanMsg(CNick&, CString const&, CString&) (in /usr/local/bin/znc)
0x48F4A1: CIRCSock::ReadLine(CString const&) (in /usr/local/bin/znc)
0x4411DE: Csock::PushBuff(char const*, unsigned long, bool) (in /usr/local/bin/znc)
0x44A50C: CSocketManager::Loop() (in /usr/local/bin/znc)
0x4483BF: CSocketManager::DynamicSelectLoop(unsigned long, unsigned long, long) (in /usr/local/bin/znc)
0x45B56E: CZNC::Loop() (in /usr/local/bin/znc)
0x430369: main (in /usr/local/bin/znc)
This, to me, certainly makes it look more Python-related, but I'd love to help track it down if I can in any way. Keep in mind, not a programmer by any means - just love the project 😄
Just for completeness, the rest of the expanded info is below in the screenshots:
The text was updated successfully, but these errors were encountered:
Hey guys,
A little while ago I mentioned in #znc about a memory leak problem I was experiencing. What was happening was that I'd start up ZNC (1.6), and about two weeks later, I'd be at my servers comfortable memory limit (gone up from 50% -> 93%) after steadily rising during its running.
I upgraded from ZNC 1.4 on the same server, which didn't have this issue at all. The only difference between the two version is that I "upgraded" from znc-push's C branch to the actively developed Python branch. This meant I needed to also compile ZNC 1.6 with modpython (which I didn't have previously). This, on one hand, makes me suspect either modpython or push as the responsible parties. However, doing a
/msg *status unloadmod push; /msg *status unloadmod modpython
does not reduce memory usage at all.Having said that, I haven't tried starting ZNC with both of these disabled - only unloading them and reloading them (as two separate tests). Aside from these, the only other modules I use are "core" modules. I can provide a breakdown if need be.
As for memory usage profiling, I've run ZNC under massif for the last few days, and each of the different functions do not grow (significantly) in usage over time, except one. The details of which are listed below:
The text of the largest snapshot, nested, are as follows:
This, to me, certainly makes it look more Python-related, but I'd love to help track it down if I can in any way. Keep in mind, not a programmer by any means - just love the project 😄
Just for completeness, the rest of the expanded info is below in the screenshots:
The text was updated successfully, but these errors were encountered: