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.
