Hi again, again,
after further investigation, I found it was indeed the ever-rolling log files
causing the performance problem. This is quite insidious, because the
slow-down is proportional to the size of the original log file, so it gets
gradually worse over time.
My immediate workaround was to stop the service, move the log files away, and
restart. This immediately resulted in much-improved performance. My long-term
solution will be to switch to the time-based rolling policy
(http://logback.qos.ch/manual/appenders.html#TimeBasedRollingPolicy) unless and
until JFrog tell me they've fixed the bug. (This might not be appropriate if
you find your logs get very large in a short space of time, but that's not an
issue for us.)
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.
From: Greene, Hugh
Sent: 19 September 2014 18:32
To: [email protected]
Subject: RE: Artifactory perfomance tuning tips?
Hi again, all,
it's really time for me to go home but, before I do, I wanted to report
something which seems quite suspicious, in case anyone happens to come back
with an answer before I get back to work on Monday :-)
While investigating, someone looking over my shoulder noticed that the
access.log files seemed to be getting rotated quite often. In fact, they seem
to be getting rotated continuously, perhaps because the original log file isn't
getting trimmed down after rotation, so remains over threshold. Using the
trick below, I can see that one file is being updated every 3-4 seconds, then
the next, then the next, and so on. Perhaps coincidentally, one of our users
said that he'd seen an initial delay of "about 4 seconds" at the start of every
request, in a recent run where he looked at detailed logs.
(The trick is adapted from
http://www.computerhope.com/forum/index.php?topic=114296.0:
forfiles /m access.*.log /c "cmd /c ECHO The last modified time of @file is:
@ftime"
)
I see at http://www.jfrog.com/confluence/display/RTF/Artifactory+Log+Files that
the etc\logback.xml file controls rotation. I haven't changed this since
install, and the file is the same as what was in place for 3.1.1.1, modulo some
insignificant whitespace changes. Maybe something else has changed in
Artifactory in this area, or maybe this is not the cause, but I'll investigate
more on Monday ...
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.
From: Greene, Hugh [mailto:[email protected]]
Sent: 19 September 2014 13:14
To:
[email protected]<mailto:[email protected]>
Subject: [Artifactory-users] Artifactory perfomance tuning tips?
Hi all,
in the last month, our interactions with our Artifactory server have been
getting painfully slow (as in, an order of magnitude slower than before), and
I'm looking for tips on how to diagnose and investigate this, or just generally
for things which are like to make performance better or worse. Other than
upgrading from 3.1.1.1 to 3.3.0 Pro, and deleting a large number of artifacts
(about 30%), we haven't made any obvious changes recently ... but we may have
made some non-obvious ones.
I haven't tried much yet-thought I'd ask for general tips before wading in.
Our setup is as follows.
* VMWare VM with
o Windows Server 2008 R2
o 300GB disk (77% used)
o 4GB RAM
o Xeon E5-2660 2.2GHz with 2 cores
* JVM start options:
JOPTS=-Xms1g;-Xmx3g;-Xss512k;-XX:PermSize=128m;-XX:MaxPermSize=256m;-XX:+UseG1GC
* Derby DB with filesystem storage
* Storage summary says
o Binaries Count: 39,343
o Binaries Size: 226.17 GB
o Artifacts Size: 267.57 GB
o Optimization: 84.53%
o Items Count: 55,043
o Artifacts Count: 45,887
I have a couple of specific questions on one bit of behaviour I have found so
far, related to Gradle (still at 1.4, because we have some complex plugins on
top, so upgrading isn't trivial). We have a custom (client-side) Gradle plugin
which gets auth details from the Windows Credential Manager, and passes them to
the usual Gradle "repositories.ivy.credentials" block. Nonetheless, Gradle
appears to make an HTTP HEAD request without authentication, then retry with
auth when it gets a 401, for every artifact. Unfortunately, the first attempt
(which appears in request.log as "non_authenticated_user") can take a couple of
minutes, and then the authenticated retry takes only a handful of milliseconds.
* What's the difference between "non_authenticated_user" (NAU) and
"anonymous", in the request.log? Is the latter only for web UI requests, or
something?
* Is there some known reason that NAU requests take a long time?
(E.g., anti-DoS, anti-hacking, etc., or some interaction with LDAP, which we
use.)
o If so, can and should I speed them up with some config setting?
Things I plan to try, once I have a fairly-repeatable way of measuring the
speed of dependency resolution, are as follow.
* Compact the DB (since we deleted a load of stuff recently).
* Prune unused artifacts (just in case that helps, but I doubt it).
* Try putting our one third-part cache (repo1) into Global Offline Mode
(so it won't be sending resolution requests through). Not sure if that'll help
much, since all the artifacts showing the above delay in the Gradle logs are
our own, but maybe it's also looking in repo1 for them.
* Try dependency resolution of the same set of artifacts using Gradle
1.4 and the latest 1.x version (without our plugins).
* Turn on extra Artifactory logging, if I can find any way to do that.
Thanks for any help you can give.
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.
______________________________________________________________________
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
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.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
