Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

  • State Not Answered
  • Replies replies
    18
  • Subscribers subscribers
    10
  • Views views
    2150
  • Users 0 members are here
  • Locked Locked
Related
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Archiving speed

davidkrotil
 

Hi,

I´m curious how many messages per seconds is normal on VMware ( average hardware , plenty of RAM, CPU , SAN etc ) , I had never more than 1,2 . Latest Retain / GroupWise, DB are PostgreSQL / MariaDB .

David

  • 0   in reply to 

    Hi Benny,

    I agree that 4 to 5 hours for this amount of messages is too long.

    I do not see a massive problem in your hard/software. Your Retain version is not really old - you miss only one version now (4.9.1.0). Because of your Retain version I do not expect your operating system is too old. Although ext3 is maybe a little bit old but it will not cause a slow Retain I assume.

    We cannot answer your question around the database. It can be mysql, mariaDB or postgres - it depends how it has been installed. At Server Configuration you will see the answer.

    In the background there are a lot of log files which tell you more; maybe at /var/log/retain-tomcat.

    However I assume that your archiving job needs inspection. Maybe this job is starting to check all entries from the very beginning instead of the last successful archiving job (you're mentioning similar).

    In your case I would open a service request to get additional help.

    Use "Verified Answers" if your problem/issue has been solved!

  • 0 in reply to   
    Hi Diethmar,

    thank for your reply. First off my bad, it's Retain 4.9.1.0 and the database is MySQL 5.5 something, which is way old but that's what's installed.
    It seems like it's checking all mesages in the PO every day. In the Retain status the amount of duplicates is almost the same as the amount of messages.
    Reading the Retain documentation page 41,42 and 196,197, is the following correct:
    In the "scope" tab of a profile
    - "Date range" "new items" are only new when they're "newer" than the timestamp set by the "Advance timestamp"
    -"new" in the context of "date range" has nothing todo with the status of an email in GW but only a relation to "Advance timestamp"

    Probably the setting "All items in mailbox" in "Date range to scan" is wrong. "Don't advance timestamp" is NOT checked.

    This system was setup years ago by another company and hardly looked after. I'm be no means a Retain expert and don't want to mess with it too much without having more experience with Retain. I certainly don't want to miss some email...

    Thank you for your time.
    Regards,
    Benny
  • 0   in reply to 

    MySQL 5.5 is not supported with 4.9.1, but this not the cause of the slowness, it´s the setting of Date Range to Scan, set it to New items and you will be fine. Anything other let as before, don´t check Don't advance timestamp . Enabling "Don't Advance Timestamp" will not update the timestamp flag. Items that are dredged will still be considered new by Retain the next time the job runs.This is useful when troubleshooting, but is generally not used for normal jobs.

    David

  • 0 in reply to   
    Hi David,
    thank you for your reply. I'm aware of the MySQL version as well as the ext3 fs. After reading the planning and install guides I verified the requirements against the current system.
    I'll set it the "new items" and see how it behaves after that.
    Could please verify my two statements in my previous post? Just so that I understand things correct.

    I expect that changing this setting will resolve some of my pain but not my curiosity. Why all the writes? It's not the logging, that's info level mostly. I don't see the fs grow apart from the daily mail ingest and some logging. What process does al the writing when handling mostly duplicates? All I know for sure is that it's retain related because retain and it's data is installed in a single fs. And when checking the amount of writes in lifetime_writes_kbytes I can see the immense amount of (re)writes (the fs isn't actually growing that much)

    Thank you for your time,
    Benny
  • 0   in reply to 

    Major I/O is from Lucene, there is in Maintenance section Enable Index Optimization, when it's set to daily, it will merge index every day, the process will use double amount of space, which is the index using. 

    You can set it ones a month, for so small system is this enough. 

    David

  • 0 in reply to   
    Hi David,
    thanks again. Index backup and rebuild is set to weekly so doesn't explain the daily I/O.
    I've changed the setting to only process new items. I'll report tomorrow about the effects.

    Regards,
    Benny
  • 0   in reply to 

    All that activity may well be Retain rewriting out the already retained email, so making those changes has a good chance of reducing the drive writes a bunch

    Also, how big are the DBs?    
    assuming default locations
       du -hx --max-depth=1 /usr/retain/mysql/

     

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    Good news, the daily job is now finished in a minute.

    The database directory is 138GB. The archive contains about 1/2 a million items. 

    Bad news, the daily delta of the vmdk's remains as high as before. I'm going to do a clean install and try to copy the data from the old server.

    Thank you for your time, I'll keep you posted.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.