On 12/6/18 1:16 PM, Vitalii Aleksandrov wrote:
This seems to be more clean, efficient, and if you don't need it, the
OS will not even allocate it (due to the demand-paging mechanism). So
I don't see where you reservations for setting a higher value of the
-M parameter come from.
Best regards,
Răzvan
Just my 2 cents about PKG mem. Indeed OS will not allocate all requested
PKG mem at the strartup. After a while if sync mechanism continues to
work continuously all worker processes will be involved at least once in
a syncing process (send or receive big amount of data). That means that
all processes will try to init that memory and OS will finally map
requested virtual memory to psychical one. When the sync is finished and
after pkg_free() called that memory becomes free and reusable from the
process point of view, but if I recall correctly how the memory manager
works (at least worked in kamailio) those chunks will be just marked as
free in internal data structure but never returned back to the OS. To
make long story short in the end after a while OS will have to really
allocate RAM for all opensips worker processes if all of them are
involved in proto_bin processing (not sure about it).
Please correct me if I'm wrong.
Hi, Vitalii!
You are absolutely right! However, syncing is not such a frequent
process, it is only done either during a restart of the backup server,
or if an MI command triggers it, not sure why, but most likely also due
to a restart of the backup server. So I'd argue only a bunch of sync
commands will be used per run, but indeed, these might occur in any process.
@Alexei, getting back to the original error, can point us the exact
error that made you think about usrloc sync-ing? I am asking because
during sync, usrloc data is sent in smaller chunks, not the entire table
at once. Therefore your assumption might be a bit misleading.
Best regards,
--
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
Meet the OpenSIPS team at the next OpenSIPS Summit:
https://www.opensips.org/events
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
