Virtual segments on SDS server
Snorri Bergmann saw 48 dynamically allocated virtual segments (134400KB) on a 14.10 SDS secondary after a heavy primary update; they stayed in use so onmode -F did not free them. David Williams suggested onstat -g afr; ZhiWei Cui reported similar cases with no cause found. Mike Walker suggested lock table expansion and checking onstat -k. Unresolved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hello everyone.
We are running 14.10 in SDS mode. Roughly 2 weeks ago a heavy update was performed on the primary which resulted in a lot of
9/29/2021 13:32:10 Dynamically allocated new virtual shared memory segment (size 134400KB)
on the secondary (48 segments were allocated). The problem is that these segments are all still in use (blkfree=1) so onmode -F won't work. No allocation took place on the primary during this update.
Is this normal?
The primary does allocate new segments from time to time but they can always be freed after the session causing the allocation has finished.
I've had this issue before and then I had to reboot the secondary to get rid of these segments.
Thanks in advance,
-Snorri
------------------------------
Snorri Bergmann
------------------------------
#Informix
onstat -g afrWhat is the fragment in each additional shared memory segment?
Which thread does that come from?
Is that ffrom a user session?
Regards,
David.
------------------------------
David Williams
------------------------------
Thanks David. I'm not sure how I can determine the thread the segment(s) belong to. But they don't belong to any running session, that's for sure. Best regards, -Snorri ------------------------------ Snorri Bergmann ------------------------------
On a stand-alone database server, I often encounter the phenomenon that there are many V segments (blkfree = 1), so onmode - F will not work.
Once, segment V was allocated quickly when an application of the developer was started. The final positioning was that there was a problem with the writing of the application.
But more often it is impossible to locate who caused it.
------------------------------
ZhiWei Cui
GBASE
ShiJiaZhuang
------------------------------
Just a thought...If the lock table was dynamically expanded during the big update, they may allocate space in additional virtual memory segments, and thereby prevent you from releasing the segments with onmode -F
If this happened, you will see messages in the Informix log, and onstat -k | tail will show if there were any lock table overflows.
------------------------------
Mike Walker
xDB Systems, Inc
www.xdbsystems.com
------------------------------
Related threads
- Posting from the Informix-list
- Migrating from IDS 9.40.UC6 to 11.50.UC3
- Ip for a network session
- questions onstat -g