I don't agree with this :). SHM has a completely different purpose (that
sharing data between processes), not just the virtue of being large. And
I'm not arguing about performance here (SHM lock, write/read
operations), but rather about things that this change will influence:
1. fragmentation issues
2. you will need to increase the SHM memory anyway to support this: if
you need let's say 1GB RAM to hold 1M dialogs, you'll need to double SHM
memory to 2GB for syncing. And if you consider that in the same time a
dlg list might come, you'll probably need 1GB more for that, reaching to
a triple amount of SHM memory. I don't find this practical.
IMO, you know better how you're going to use the system, and if you do
want to do usrloc/dialog sync for large amount of data, just set the PKG
value to the same of SHM. 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
On 12/5/18 11:11 PM, vasilevalex wrote:
Hi all,
Thank you @Liviu, this is exactly what I mean. Either use SHM or may be
split all data into smaller parts to fit PKG memory. This is just thoughts.
Because if people start using real data in cluster they will reach PKG limit
very fast.
--
Sent from:
http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
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
