No problem. I think that sometime you will decide to tune the OrientDB perfomance, it is can be done with the following :
- use the OpenJDK only - limit the Linux kernel used memory size say to 2G (use mem=2G kernel parameter) - limit the CPU cores to 1 or 2 (maxcpus=2 kernel parameter) - use the slowest HDD ;) So you can try the Raspberry again ;) Cheers ! Rus воскресенье, 18 мая 2014 г., 11:09:56 UTC+3 пользователь Andrey Lomakin написал: > > 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]<javascript:> > > 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]<javascript:> >> > 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] <javascript:>. >>> 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.
