Hi, Profiler could be wrong, depending how you called it. For example in YourKit sampling is more accurate on this, while classic profiling could give wrong hotspots (happen hundreds of times).
Lvc@ On 9 December 2014 at 08:06, Adithyan K <[email protected]> wrote: > Andrey, > > Thank you so much! > > I made one wrong statement while explaining the issue. > i.e., I have said that it is due to synchronized (rndFile). But, it is not > true. In Thread dump when I saw, more than 90% of the Thread's time is > spent in the below highlighted lines. > > java.lang.Thread.State: RUNNABLE > * at java.util.zip.CRC32.updateBytes(Native Method)* > * at java.util.zip.CRC32.update(CRC32.java:65)* > * at > com.orientechnologies.orient.core.storage.impl.local.paginated.wal.ODiskWriteAheadLog$LogSegment.checkPageIntegrity(ODiskWriteAheadLog.java:565)* > at > com.orientechnologies.orient.core.storage.impl.local.paginated.wal.ODiskWriteAheadLog$LogSegment.readRecord(ODiskWriteAheadLog.java:402) > at > com.orientechnologies.orient.core.storage.impl.local.paginated.wal.ODiskWriteAheadLog.read(ODiskWriteAheadLog.java:876) > > Does the line still hold good > > It will be fixed at given issue https://github.com/ > orientechnologies/orientdb/issues/2874 . > > > Thanks > > Reg, > > K Adithyan > > > > > On Tuesday, December 9, 2014 12:14:21 PM UTC+5:30, Andrey Lomakin wrote: >> >> Hi, >> Thank you for your report. >> It will be fixed at given issue https://github.com/ >> orientechnologies/orientdb/issues/2874 . >> So we will not need to do rollback on file level. >> >> >> On Mon, Dec 8, 2014 at 10:11 PM, Adithyan K <[email protected]> wrote: >> >>> Team, >>> >>> Used OrientVersion : 2.0-M3 >>> >>> >>> This is my observation. ODatabaseDocumentTx.commit() takes around 4 >>> seconds for some number of documents if the commit is successful. But, when >>> the ORecordDuplicateException is thrown by the commit() method, this >>> method takes around 30 seconds for the same number of records. When I >>> perform commit, during the ORecordDuplicateException, the >>> ODatabaseDocumentTx.commit() internally calls rollback method and this >>> takes more than 95% of the time. >>> >>> With JMC, when I analysed, I found that the >>> ODiskWriteAheadLog.readRecord(OLogSequenceNumber) method's >>> synchronized(rndFile) statement is blocking my writing Thread for more than >>> 90% of the time of the commit() method. Pls find the attached screenshot. >>> >>> Another input is : Only one Thread in my application writes in to >>> OrientDB. >>> >>> So, I have doubt who else has acquired the monitor of rndFile for so >>> long time that too only during rollback call inside commit(). When there is >>> no duplication issue, entire commit() successfully returns within 4 seconds. >>> >>> Expecting feedback whether I am able to present my point.. >>> Pls revert to me if I have to give any other information >>> >>> I am also trying to take thread dump during this rollback time to check >>> which Thread has acquired this rndFile... I will give further inputs on >>> this I am successful on this. >>> >>> Reg, >>> >>> K Adithyan >>> >>> >>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Best regards, >> Andrey Lomakin. >> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
