Hi Alex,
thanks for your suggestions, but I don't think any of them apply to us.
The files were on the same drive as the Artifactory install, with plenty of
free space and low disk I/O usage. I also used SysInternals Process Explorer
to verify that only the Artifactory EXE had handles open on the file, and that
it had two handles open, in the problem case.
I'm not surprised that you couldn't reproduce it, because I couldn't, either!
That is, I got the same behaviour on our production server even after
restarting the service (and checking that all file handles were released), but
was unable to reproduce the problem with a fresh install of Artifactory on a
separate machine (my desktop PC), even when I dropped the same log files into
its logs folder.
As for reducing the maximum size, the log file was already, at about 94MB, well
over the default maximum size of 25MB. The problem was that the roll-over
process wasn't working as intended, as could be seen by looking at file
operations using SysInternals Process Monitor. The Artifactory process
successfully zipped "access.log" to one of the 9 "access.<n>.log.zip" files,
then tried to overwrite the original "access.log" file with an empty file --
but that failed, because the same Artifactory process had a second handle open
on the file. (Watching the same behaviour in my local install, I could see
this second step succeed.) This happened on every log message, taking 3-4
seconds each time.
So, I'm pretty convinced that Artifactory got into a bad state somehow, but I
don't know how.
I have now replaced the logging with a time-based policy, like this:
<appender name="ACCESS"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<rollingPolicy
class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>${artifactory.home}/logs/%d{yyyy,aux}/access.%d{yyyy-MM}.log.gz</FileNamePattern>
</rollingPolicy>
<encoder>
<pattern>%d %m%n</pattern>
</encoder>
</appender>
This means that Artifactory no longer writes an "logs\access.log", only
"logs\2014\access.2014-10.log" etc. I've put a dummy log file in place at
"logs\access.log" with a message directing people to look in the appropriate
network share folder, so that admins who look at the logs in the web UI won't
be confused by an empty log. I've done the same for the other four logs, just
in case, even though we only had a problem with the access.log.
Regards,
Hugh Greene, Senior Software Developer
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799
http://www.tmvse.com / mailto:[email protected]
DISCLAIMER
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this message and/or attachments
is strictly prohibited. The company accepts no liability for any damage caused
by any virus transmitted by this email. Furthermore, the company does not
warrant a proper and complete transmission of this information, nor does it
accept liability for any delays. If you have received this message in error,
please contact the sender and delete the message.
-----Original Message-----
From: Alex [mailto:[email protected]]
Sent: 05 October 2014 11:52
To: [email protected]
Subject: Re: [Artifactory-users] Artifactory perfomance tuning tips?
Hi Hugh
We tried reproducing the issue you reported regarding the log file size but
couldn’t successfully reproduce it on several scenarios.
In your case this issue might also be related either to I/O issues or network
connectivity issues in case your log files are located on a network drive.
If this is not the issue in your case, you can decrease your log file’s maximum
size, keeping the log file size to a size that does not affect your server’s
performance; This can be done by modifying the
${artifactory_home}/etc/logback.xml file:
Just edit the relevant appender’s <MaxFileSize> tag (for the artifactory.log,
the appender name is "FILE").
Please modify the size of the file to your desired size.
For example:
<MaxFileSize>15MB</MaxFileSize>
Regards,
Alex
--
View this message in context:
http://forums.jfrog.org/Artifactory-perfomance-tuning-tips-tp7579987p7579997.html
Sent from the Artifactory - Users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS
3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready
for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0
Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
