Re: [foxboro] CP40A largest segment of free memory too small

Ken,
        Unfortunately, rebooting one at a time won't fix the problem.  When you 
reboot one of a FT pair it only reloads the base operating system and 
then checks to see if it is the Primary CP.  If there is already a 
Primary in operation it then mirrors the Primary memory and retains the 
problem.  If it doesn't find a Primary in operation it loads it's memory 
based on the checkpoint file but lays things down in contiguous memory 
and acts like a RAM memory defrag.  If you have set a value in CSPACE 
that is larger than a SEQ blocks CSIZE value the CP will  essentially 
reserve the additional memory so you will be able to edit and add to 
that sequence in the future without moving to another memory location.
        By deleting/undeleting the block, you may have removed the sequence 
from memory, and because there was free memory before and after the 
memory location of the deleted sequence, created contiguous memory large 
enough to reload the new code additions.  I am surprised that you were 
able to get it done without a CP reboot, but you were one of the lucky 
ones.  Congratulations!
Tom

Moore, Kenneth, Celanese/US wrote:
> The block was 12000 plus before the edit, I guess when I increased CSPACE to 
> 15000, there was enough nearby memory to allow the approx. 3k increase. I'm 
> just glad it worked, because a CP reboot would not be possible until sometime 
> mid-March.
> One quick question on your reboot recommendation, this is a fault tolerant 
> pair, will rebooting each CP individually, (not disturbing the process) 
> result in the same memory optimization? If so I could do this anytime the 
> process isn't at a critical stage.
> 
> 
> 
> Ken Moore
> Celanese
> Enoree, SC 29335
> 
> 
> 
> 
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx on behalf of Johnson, Alex P (IPS)
> Sent: Wed 2/21/2007 7:40 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] CP40A largest segment of free memory too small
>  
> Ken,
> 
> You wrote earlier that the "largest segment is 11008 bytes" and you
> state now that the block requires 13487 bytes.
> 
> At this point, the only options are:
> 
> 1) Checkpoint the CP and reboot it. You do not need to upload and
> initialize as one writer said. The CP repacks its RAM on reboot.
> 2) Split the block into two blocks each smaller than 11008 bytes.
> 
> The CP does not do "garbage collection." All it can do for memory
> management is try to fit blocks into space left by previous deletions.
> Once a block gets too big for the biggest available space, it cannot be
> added.
> 
> I hope that this information is of some benefit.
> 
> Regards,
> 
> Alex Johnson
> Invensys Systems, Inc.
> 10900 Equity Drive
> Houston, TX 77041
> 713.329.8472 (voice)
> 713.329.1700 (fax)
> 713.329.1600 (switchboard)
> alex.johnson@xxxxxxxxxxxxxxxx
> 
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Moore, Kenneth, Celanese/US
> Sent: Wednesday, February 21, 2007 4:30 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] CP40A largest segment of free memory too small
> 
>  CSPACE was 0, Changed to 15000, check pointed, same error.
>  Trimmed the message strings approx. 40%, same error.
>  Deleted and undeleted IND block, compiled, and done, without error.
>  SUCCESS!!!!
> 
> I think once I changed CSPACE to 15000, it didn't do anything until the
> delete/undelete.
> Now detailed display shows CSIZE 13487 and CSPACE 15000
> 
> 
> Regards,
> 
> Ken Moore
> 
> Celanese Emulsions
> Enoree, SC 29335
> 
> 
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of tom.vandewater@xxxxxxxxxxxxxx
> Sent: Wednesday, February 21, 2007 3:59 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] CP40A largest segment of free memory too small
> 
> Ken,
>       I just remembered one more potential gotcha on the sequence
> compiler error.  I remember running into a limit on the amount of text
> characters that the compiler can handle when using the SENDMSG command
> in the code.  If you have defined a large amount of SENDMSG character
> strings in your code the compiler chokes and gives an error message that
> isn't very descriptive such as the one you listed in your note.  You
> could shorten each of your SENDMSG strings or remove some of the
> messages entirely and see if it solves your problem.  It would be
> appreciated if you respond to the list with whatever you find to be your
> solution.
> Thanks,
> Tom VandeWater
> 
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Moore, Kenneth, Celanese/US
> Sent: Wednesday, February 21, 2007 1:20 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] CP40A largest segment of free memory too small
> 
>  Hi List,
> By kind, I'm just a novice.
> I have an Independent Sequence Block, that has a tremendous amount of
> HLBL, roughly 20 pages.
> I need to alter the logic slightly, everything compiles okay, when I go
> to save it, I get error E-35, not enough memory for block, the new logic
> is approx. 1/2 page shorter than the old logic.
> I don't know how the memory is handled through the ICC. The station
> block shows that the largest segment is 11008 bytes, with total free
> being 390648 bytes. Idle time is approx. 50%
> 
> I suspect my problem is the size largest segment. How can I "re-arrange"
> the memory to have a larger segment available?
> 
> 
> Regards,
> 
> Ken Moore
> Celanese Emulsions
> Enoree, SC 29335
> 
> =3D3D20
> =3D3D20
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
> =3D3D20
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         =3D3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Djoin
> to unsubscribe:      =3D3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Dleave
> =3D3D20
> =3D20
> =3D20
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
> =3D20
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         =3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
> to unsubscribe:      =3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
> =3D20
>  =
> 
>  =
> 
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>  =
> 
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
>  =
> 
> 
> 
> 
> Confidentiality Notice:
> The information contained in this electronic message and any attachment(s) =
> to this message are intended for the exclusive use of the recipient(s) and =
> may contain confidential, privileged or proprietary information. If you are=
>  not the intended recipient, please notify the sender immediately, delete a=
> ll copies of this message and any attachment(s). Any other use of the E-Mai=
> l by you is prohibited.
> 
> 
>  
>  
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>  
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>  
> 
> 
> -- No attachments (even text) are allowed --
> -- Type: application/ms-tnef
> -- File: winmail.dat
> 
> 
>  
>  
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>  
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>  
> 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: