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

-- 

--- 
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.

Reply via email to