-
Type:
Bug
-
Resolution: Obsolete
-
Priority:
Medium
-
None
-
Affects Version/s: 1.5.5
-
Component/s: Indexing
Created from FSH-991.
When indexing everything in a large (755Mb, 19887 revisions) Subversion repository, Fisheye is importing very slowly towards the end (eg. 1 revision per 10s). Memory use is stable at (after a full GC) 190Mb free of 298Mb claimed, with a 512Mb Xmx. There is no swapping going on:
$ vmstat 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 1828 260884 111568 1185872 0 0 1 51 18 12 2 1 97 0 0 1 0 1828 260884 111576 1185932 0 0 0 952 3122 5767 30 4 65 1 1 1 0 1828 260628 111580 1185996 0 0 0 861 1364 5294 36 7 55 1 0 1 0 1828 260736 111584 1186128 0 0 5 1665 2399 5010 32 5 62 1 1 1 0 1828 260240 111600 1186248 0 0 0 564 759 3684 43 6 51 1 0 2 0 1828 260388 111604 1186312 0 0 0 1190 3787 15131 60 18 21 1 1 4 0 1828 260272 111616 1186368 0 0 0 1356 4469 17514 67 17 15 0 1
Attached are some thread dumps (threaddumps.txt), and they seem to indicate that inifinitydb is the bottleneck.
The thread dumps seem to indicate that the db is waiting for I/O.
"InfinityDB Cell I/O" daemon prio=1 tid=0x08893068 nid=0x7f90 in Object.wait() [0x85efe000..0x85eff030] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:474) at com.infinitydb.d.a(InfinityDB_1.0.53:181) - locked <0x927c77d8> (a com.infinitydb.d) at com.infinitydb.j.run(InfinityDB_1.0.53:184) at java.lang.Thread.run(Thread.java:595)
The previous dumps before this, show that it is trying to add a new path info.
"pool-2-thread-1" prio=1 tid=0x0aac35f8 nid=0x7f95 runnable [0x86747000..0x86747db0] at java.util.zip.Deflater.deflateBytes(Native Method) at java.util.zip.Deflater.deflate(Deflater.java:284) - locked <0x927c7af0> (a java.util.zip.Deflater) at java.util.zip.Deflater.deflate(Deflater.java:296) at com.infinitydb.j.o(InfinityDB_1.0.53:812) at com.infinitydb.j.n(InfinityDB_1.0.53:794) - locked <0x927c8d70> (a [B) at com.infinitydb.j.f(InfinityDB_1.0.53:455) - locked <0x927c7800> (a com.infinitydb.j) at com.infinitydb.InfinityDB.b(InfinityDB_1.0.53:3183) at com.infinitydb.InfinityDB.a(InfinityDB_1.0.53:3090) at com.infinitydb.InfinityDB.f(InfinityDB_1.0.53:1593) - locked <0x927c7670> (a com.infinitydb.InfinityDB) at com.infinitydb.InfinityDB.next(InfinityDB_1.0.53:1866) at com.infinitydb.InfinityDB.next(InfinityDB_1.0.53:1857) at com.infinitydb.CharacterLongObjectReader.a(InfinityDB_1.0.53:153) at com.infinitydb.CharacterLongObjectReader.read(InfinityDB_1.0.53:131) at com.cenqua.fisheye.infinitydb.UniqueStringTable.get(UniqueStringTable.java:101) at com.cenqua.fisheye.infinitydb.UniqueStringTable.find(UniqueStringTable.java:133) at com.cenqua.fisheye.infinitydb.UniqueStringTable.find(UniqueStringTable.java:113) at com.cenqua.fisheye.infinitydb.UniqueStringTable.add(UniqueStringTable.java:221) - locked <0x927c6e30> (a java.lang.Object) at com.cenqua.fisheye.svn.db.SvnRevInfoDAO.updateLogicalPathInfo(SvnRevInfoDAO.java:169) at com.cenqua.fisheye.svn.db.SvnRevInfoDAO.insertNew(SvnRevInfoDAO.java:61)
Which for some reason, (not quite certain at this point) leads to the fact that the db needs to deflate a zip and then later inflate it
"InfinityDB Cell I/O" daemon prio=1 tid=0x08893068 nid=0x7f90 runnable [0x85efe000..0x85eff030] at java.util.zip.Inflater.inflateBytes(Native Method) at java.util.zip.Inflater.inflate(Inflater.java:215) - locked <0x927c7b20> (a java.util.zip.Inflater) at java.util.zip.Inflater.inflate(Inflater.java:232) at com.infinitydb.j.k(InfinityDB_1.0.53:690) - locked <0x927c8d70> (a [B) - locked <0x927c77c0> (a java.io.RandomAccessFile) at com.infinitydb.j.l(InfinityDB_1.0.53:762) at com.infinitydb.j.d(InfinityDB_1.0.53:435) - locked <0x927c7800> (a com.infinitydb.j) at com.infinitydb.j.g(InfinityDB_1.0.53:219) at com.infinitydb.j.run(InfinityDB_1.0.53:191) - locked <0x92a8e7b8> (a com.infinitydb.h) at java.lang.Thread.run(Thread.java:595)
Checking VMStat again we can see that I/O was very busy:
It's very busy writing to the disk. 'bo' stands for 'bytes out', which means bytes written to the disk: $ vmstat 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 1828 182920 115732 1251272 0 0 1 53 20 20 2 1 97 0 0 1 0 1828 182812 115736 1251404 0 0 0 1554 1021 5947 35 10 53 2 0 1 0 1828 182556 115744 1251532 0 0 0 1466 1865 6367 32 9 58 1 0 3 0 1828 182192 115748 1251664 0 0 0 1626 1467 5345 37 7 54 1 0 1 0 1828 182068 115752 1251796 0 0 0 1551 1373 5820 34 8 55 2 0 4 0 1828 174292 115768 1251984 0 0 0 1894 3241 6494 29 7 62 1 1 2 0 1828 180616 115776 1252044 0 0 0 2022 3039 14690 67 19 13 0 1 2 0 1828 180560 115788 1252236 0 0 0 3646 3280 14992 58 19 16 6 1 1 0 1828 180468 115796 1252296 0 0 0 2056 2065 8275 40 14 42 4 0 1 0 1828 180656 115800 1252428 0 0 0 1534 3739 6984 26 6 66 1 1 1 0 1828 180564 115808 1252556 0 0 0 1502 1035 5911 37 9 53 1 0 2 0 1828 180184 115816 1252684 0 0 0 1873 2312 6362 31 6 60 2 0 1 0 1828 180184 115828 1252808 0 0 0 1448 1198 6146 34 9 55 1 0 1 0 1828 180084 115836 1252868 0 0 0 1499 2282 6360 29 8 61 1 1 1 1 1828 179828 115836 1253004 0 0 0 1664 1560 5620 35 7 56 1 0 1 1 1828 179464 115844 1253132 0 0 0 1595 3010 6066 30 4 64 1 1 1 0 1828 179340 115852 1253328 0 0 0 1581 3131 6598 29 5 64 1 1
- relates to
-
FE-4760 Locking issues on scanning/indexing a svn-repository via http
- Closed