Sorry for later delay we have enormous amount of tasks to do.
On Sun, May 18, 2014 at 11:09 AM, Andrey Lomakin <[email protected]>wrote: > Hi, > The point here that you always in swap, you see you have 2gb of ram but > disk cache by default has 4gb. > Could you kindle set the parameter storage.diskCache.bufferSize to 1024 > and try your test ? > > > On Sun, May 18, 2014 at 8:12 AM, Sfinx <[email protected]> wrote: > >> Hi Luca, >> >> Never mind - switched to MongoDB. Seems like running OrientDB on such low >> hardware was initially bad idea ;) >> >> [proto]:root:/Arhiv/mongo # echo "{nThreads:1,fileSizeMB:1,r:true}" | >> /opt/mongo/bin/mongoperf >> mongoperf >> use -h for help >> parsed options: >> { nThreads: 1, fileSizeMB: 1, r: true } >> creating test file size:1MB ... >> testing... >> optoins:{ nThreads: 1, fileSizeMB: 1, r: true } >> wthr 1 >> new thread, total running : 1 >> read:1 write:0 >> 5343 ops/sec 20 MB/sec >> 5384 ops/sec 21 MB/sec >> 5359 ops/sec 20 MB/sec >> 5397 ops/sec 21 MB/sec >> 5389 ops/sec 21 MB/sec >> 5341 ops/sec 20 MB/sec >> ^C >> >> >> >> >> среда, 14 мая 2014 г., 11:03:07 UTC+3 пользователь Sfinx написал: >> >>> Hi Luca, >>> >>> Please see the attached VisualVM and YourKit snapshots made during >>> importing src/test/resources/graph-example-2.xml to the snapshot branch >>> under OpenJDK. Another bottleneck noticed when deleting records from the >>> table using simple "delete * from" SQL statement. Can profile this too if >>> interested. >>> >>> Rus >>> >>> понедельник, 12 мая 2014 г., 19:46:13 UTC+3 пользователь Lvc@ написал: >>>> >>>> Hi Rus, >>>> could you profile the server on such HW/SW cfg (JVisualVM or better >>>> YourKit)? When we tested OrientDB on Raspberry we found many bottlenecks >>>> detectable only on such architecture. >>>> >>>> Lvc@ >>>> >>>> >>>> >>>> Lvc@ >>>> >>>> >>>> On 12 May 2014 18:30, Sfinx <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> The specifying -Dmemory.useUnsafe=false prevented the hangs (thanks >>>>> for hint !), the second option do not influence at all. Though insert >>>>> speed >>>>> is still too low (counting that database dir resides as fast SSD and the >>>>> object is the dummy object from the post.txt): >>>>> >>>>> ........ >>>>> [proto]:root:/opt/orientdb/benchmarks # ab -n1000 -A root:root_pass >>>>> -k -c2 -p post.txt http://127.0.0.1:2480/document/demo/9:1 >>>>> This is ApacheBench, Version 2.3 <$Revision: 1528965 $> >>>>> Copyright 1996 Adam Twiss, Zeus Technology Ltd, >>>>> http://www.zeustech.net/ >>>>> Licensed to The Apache Software Foundation, http://www.apache.org/ >>>>> >>>>> Benchmarking 127.0.0.1 (be patient) >>>>> Completed 100 requests >>>>> Completed 200 requests >>>>> Completed 300 requests >>>>> Completed 400 requests >>>>> Completed 500 requests >>>>> Completed 600 requests >>>>> Completed 700 requests >>>>> Completed 800 requests >>>>> Completed 900 requests >>>>> Completed 1000 requests >>>>> Finished 1000 requests >>>>> >>>>> >>>>> Server Software: OrientDB >>>>> Server Hostname: 127.0.0.1 >>>>> Server Port: 2480 >>>>> >>>>> Document Path: /document/demo/9:1 >>>>> Document Length: 123 bytes >>>>> >>>>> Concurrency Level: 2 >>>>> Time taken for tests: 17.209 seconds >>>>> Complete requests: 1000 >>>>> Failed requests: 0 >>>>> Keep-Alive requests: 1000 >>>>> Total transferred: 486503 bytes >>>>> Total body sent: 320000 >>>>> HTML transferred: 123000 bytes >>>>> Requests per second: * 58.11 *[#/sec] (mean) >>>>> Time per request: 34.419 [ms] (mean) >>>>> Time per request: 17.209 [ms] (mean, across all concurrent >>>>> requests) >>>>> Transfer rate: 27.61 [Kbytes/sec] received >>>>> 18.16 kb/s sent >>>>> 45.77 kb/s total >>>>> >>>>> Connection Times (ms) >>>>> min mean[+/-sd] median max >>>>> Connect: 0 0 0.3 0 10 >>>>> Processing: 11 34 26.9 31 487 >>>>> Waiting: 11 34 26.9 31 487 >>>>> Total: 11 34 27.1 31 490 >>>>> >>>>> Percentage of the requests served within a certain time (ms) >>>>> 50% 31 >>>>> 66% 36 >>>>> 75% 40 >>>>> 80% 43 >>>>> 90% 54 >>>>> 95% 63 >>>>> 98% 80 >>>>> 99% 93 >>>>> 100% 490 (longest request) >>>>> [proto]:root:/opt/orientdb/benchmarks # >>>>> ........... >>>>> >>>>> So deleting from the table took too much : >>>>> >>>>> ..... >>>>> orientdb {demo}> select count(*) from Devices; >>>>> >>>>> ----+------+----- >>>>> # |@RID |count >>>>> ----+------+----- >>>>> 0 |#-1:-1|8207 >>>>> ----+------+----- >>>>> >>>>> 1 item(s) found. Query executed in 0.017 sec(s). >>>>> orientdb {demo}> delete from Devices >>>>> >>>>> Delete record(s)* '8261' in 30.190001 sec(s).* >>>>> >>>>> orientdb {demo}> >>>>> ........ >>>>> >>>>> >>>>> Rus >>>>> >>>>> понедельник, 12 мая 2014 г., 19:16:41 UTC+3 пользователь Lvc@ написал: >>>>>> >>>>>> Hi, >>>>>> Can you run the server by trying a combination of these options (edit >>>>>> bin/server.sh, last line)? >>>>>> >>>>>> -Djna.disable.system.library=true >>>>>> -Dmemory.useUnsafe=false >>>>>> >>>>>> Lvc@ >>>>>> >>>>>> >>>>>> Lvc@ >>>>>> >>>>>> >>>>>> On 12 May 2014 18:06, Sfinx <[email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Ok, for the Oracle java version ["1.7.0_55" Java(TM) SE Runtime >>>>>>> Environment (build 1.7.0_55-b13) Java HotSpot(TM) Client VM (build >>>>>>> 24.55-b03, mixed mode)] I have the following results : >>>>>>> >>>>>>> - graph-example-2.xml insert time is *154536ms *- nearly the same >>>>>>> as at 1.8.0 >>>>>>> - the fault error still present : >>>>>>> ....... >>>>>>> [proto]:root:/opt/orientdb/benchmarks # ab -n1000 -A root:root_pass >>>>>>> -k -c10 -p post.txt http://127.0.0.1:2480/document/demo/9:1 >>>>>>> This is ApacheBench, Version 2.3 <$Revision: 1528965 $> >>>>>>> Copyright 1996 Adam Twiss, Zeus Technology Ltd, >>>>>>> http://www.zeustech.net/ >>>>>>> Licensed to The Apache Software Foundation, http://www.apache.org/ >>>>>>> >>>>>>> Benchmarking 127.0.0.1 (be patient) >>>>>>> Completed 100 requests >>>>>>> apr_pollset_poll: The timeout specified has expired (70007) >>>>>>> Total of 124 requests completed >>>>>>> [proto]:root:/opt/orientdb/benchmarks # >>>>>>> ........ >>>>>>> 2014-05-12 15:56:42:308 INFO OrientDB Server v1.7-SNAPSHOT is >>>>>>> active. [OServer] >>>>>>> 2014-05-12 15:56:57:053 INFO - Rebuilding index demo.dictionary... >>>>>>> [OIndexRebuildOutputListener] >>>>>>> 2014-05-12 15:56:57:066 INFO --> OK, indexed 0 items in 14 ms >>>>>>> [OIndexRebuildOutputListener] >>>>>>> 2014-05-12 15:57:05:450 INFO Created database 'demo' of type >>>>>>> 'plocal' [ONetworkProtocolBinary] >>>>>>> 2014-05-12 15:58:40:951 SEVE Internal server error: >>>>>>> java.lang.InternalError: a fault occurred in a recent unsafe memory >>>>>>> access operation in compiled Java code [ONetworkProtocolHttpDb] >>>>>>> ........ >>>>>>> >>>>>>> I see that fault error happens sporadically even when using low "ab >>>>>>> -n" numbers, but using high (>= 1000) will hang the server immediatly. >>>>>>> >>>>>>> >>>>>>> Rus >>>>>>> >>>>>>> понедельник, 12 мая 2014 г., 18:41:27 UTC+3 пользователь Lvc@написал: >>>>>>>> >>>>>>>> Hi, >>>>>>>> That errors seems caused by JVM as internal... To understand if >>>>>>>> it's Java8 or new snapshot, can you run new 1.7-snapshot against JDK7? >>>>>>>> >>>>>>>> Lvc@ >>>>>>>> >>>>>>>> >>>>>>>> Lvc@ >>>>>>>> >>>>>>>> >>>>>>>> On 12 May 2014 17:33, Sfinx <[email protected]> wrote: >>>>>>>> >>>>>>>>> the fault message never appears if I use "ab -n 100". using "ab >>>>>>>>> -n 200" and higher immediatly triggers server hang. >>>>>>>>> >>>>>>>>> >>>>>>>>>> ....... >>>>>>>>>> ab -n1000 -A root:root_pass -k -c2 -p post.txt >>>>>>>>>> http://127.0.0.1:2480/document/demo/9:1 >>>>>>>>>> This is ApacheBench, Version 2.3 <$Revision: 1528965 $> >>>>>>>>>> Copyright 1996 Adam Twiss, Zeus Technology Ltd, >>>>>>>>>> http://www.zeustech.net/ >>>>>>>>>> Licensed to The Apache Software Foundation, >>>>>>>>>> http://www.apache.org/ >>>>>>>>>> >>>>>>>>>> Benchmarking 127.0.0.1 (be patient) >>>>>>>>>> Completed 100 requests >>>>>>>>>> apr_pollset_poll: The timeout specified has expired (70007) >>>>>>>>>> Total of 184 requests completed >>>>>>>>>> ...... >>>>>>>>>> 2014-05-12 14:56:14:208 SEVE Internal server error: >>>>>>>>>> java.lang.InternalError: a fault occurred in a recent unsafe >>>>>>>>>> memory access operation in compiled Java code >>>>>>>>>> [ONetworkProtocolHttpDb] >>>>>>>>>> ...... >>>>>>>>>> >>>>>>>>>> The OrientDB server have been hunged, so restart needed. >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> --- >>>>>>>>> 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. >>>>>>> >>>>>> >>>>>> -- >>>>> >>>>> --- >>>>> 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. >> > > > > -- > Best regards, > Andrey Lomakin. > > Orient Technologies > the Company behind OrientDB > > -- Best regards, Andrey Lomakin. Orient Technologies the Company behind OrientDB -- --- 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.
