Difference: PurgingTheUSAGEFile (1 vs. 3)

Revision 32016-01-22 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="SystemAdministration"

Purging the USAGE File

Changed:
<
<

Prior to APPX Release 3.5, APPX periodically performed a "cleanup" and removed entries from the USAGE file for sessions that no longer existed. This "cleanup" operation was disabled in APPX 3.5 and higher to improve License Server reliability.

>
>

The USAGE files ($APPXPATH/0SA/USAGE.*) track numbers of endusers, designers, and users of locked applications currently logged into APPX. Prior to APPX Release 3.5, APPX periodically performed a "cleanup" and removed entries from the USAGE file for sessions that no longer existed. This "cleanup" operation was disabled in APPX 3.5 and higher to improve License Server reliability.

 
Changed:
<
<
The USAGE files ($APPXPATH/0SA/USAGE.*) track numbers of endusers, designers, and users of locked applications currently logged into APPX.

APPX still removes a session's entry from the USAGE file if that user exits from APPX normally. If the user does not exit normally, then the entry for that session remains in the USAGE file indefinitely.

Jean Neron of CANSYS West developed the following procedure to trim the USAGE file 'on the fly':

>
>
APPX still removes a session's entry from the USAGE file if that user exits from APPX normally. If the user does not exit normally, then the entry for that session remains in the USAGE file indefinitely. A large or corrupt USAGE file can slow the login process. The following procedure can be used to trim the USAGE file 'on the fly':
 

  1. Open a command shell, and export APPX_LS_GHOSTS=true.
  2. From the same command shell, kill the license server.
Changed:
<
<
  1. From the same command shell, start the license server.

    Since the APPX_LS_GHOSTS variable is set, it will remove all the dead entries in the USAGE file as part of it's start up. It's possible that in between steps 2 and 3, someone else tries to log on to APPX, which will cause the license server to start, but the LS_GHOSTS won't be set in that users environment, so it won't clean the file. If this happens, just repeat 2) and 3) until you start the license server.

  2. Unset the APPX_LS_GHOSTS variable. (Or just close the shell & open a new one).
>
>
  1. From the same command shell, start the license server.

    Since the APPX_LS_GHOSTS variable is set, it will remove all the dead entries in the USAGE file as part of it's start up. It's possible that in between steps 2 and 3, someone else tries to log on to APPX, which will cause the license server to start, but the LS_GHOSTS won't be set in that users environment, so it won't clean the file. If this happens, just repeat 2) and 3) until you start the license server.
  2. Unset the APPX_LS_GHOSTS variable. (Or just close the shell & open a new one).
 
  1. Kill & restart the license server.
Now it will be running without LS_GHOSTS set, and you won't be running the risk of having the USAGE file corrupted.
Line: 21 to 17
  We did this on a running system, and the USAGE file went from 8000+ records to 35 in the blink of an eye, with performance increasing accordingly, all while a couple dozen users were on the system.
Added:
>
>
If you suspect your USAGE file is corrupt, then your only solution is to get everyone to log off, kill any remaining appx processes and erase $APPXPATH/0SA/Data/USAGE.*. The next user to log in will cause a new USAGE file to be created.
 

Comments:

Read what other users have said about this page or add your own comments.

Revision 22012-02-29 - ChrisBrower

Line: 1 to 1
 
META TOPICPARENT name="SystemAdministration"

Purging the USAGE File

Prior to APPX Release 3.5, APPX periodically performed a "cleanup" and removed entries from the USAGE file for sessions that no longer existed. This "cleanup" operation was disabled in APPX 3.5 and higher to improve License Server reliability.

Line: 22 to 20
 How can you check to see if this worked? Before you start, use the System Admin file management to verify the USAGE file before you start, and then check it again after you are done.

We did this on a running system, and the USAGE file went from 8000+ records to 35 in the blink of an eye, with performance increasing accordingly, all while a couple dozen users were on the system.

Added:
>
>

Comments:

Read what other users have said about this page or add your own comments.



<--/commentPlugin-->
 \ No newline at end of file

Revision 12012-02-27 - ChrisBrower

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="SystemAdministration"

Purging the USAGE File

Prior to APPX Release 3.5, APPX periodically performed a "cleanup" and removed entries from the USAGE file for sessions that no longer existed. This "cleanup" operation was disabled in APPX 3.5 and higher to improve License Server reliability.

The USAGE files ($APPXPATH/0SA/USAGE.*) track numbers of endusers, designers, and users of locked applications currently logged into APPX.

APPX still removes a session's entry from the USAGE file if that user exits from APPX normally. If the user does not exit normally, then the entry for that session remains in the USAGE file indefinitely.

Jean Neron of CANSYS West developed the following procedure to trim the USAGE file 'on the fly':


  1. Open a command shell, and export APPX_LS_GHOSTS=true.
  2. From the same command shell, kill the license server.
  3. From the same command shell, start the license server.

    Since the APPX_LS_GHOSTS variable is set, it will remove all the dead entries in the USAGE file as part of it's start up. It's possible that in between steps 2 and 3, someone else tries to log on to APPX, which will cause the license server to start, but the LS_GHOSTS won't be set in that users environment, so it won't clean the file. If this happens, just repeat 2) and 3) until you start the license server.

  4. Unset the APPX_LS_GHOSTS variable. (Or just close the shell & open a new one).
  5. Kill & restart the license server.
Now it will be running without LS_GHOSTS set, and you won't be running the risk of having the USAGE file corrupted.

How can you check to see if this worked? Before you start, use the System Admin file management to verify the USAGE file before you start, and then check it again after you are done.

We did this on a running system, and the USAGE file went from 8000+ records to 35 in the blink of an eye, with performance increasing accordingly, all while a couple dozen users were on the system.

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback