Strange results when executing a long-running query

[Phil John]

I've just checked out the latest git HEAD, compiled and installed, and when running the following query:

SELECT (count(?s) as ?count) WHERE { GRAPH <http://graph/uri/goes/here> { ?s ?p ?o } }

with a soft-limit of -1, requests to the /status/ URI on 4s-http yields the following:

SPARQL httpd server status - size

KB pjohn

ID�

Segment #	quads (s)	quads (sr)	models	resources
Unexpected error fetching size info from segment
Unexpected error fetching size info from segment
Unexpected error fetching size info from segment
Unexpected error fetching size info from segment
Unexpected error fetching size info from segment
Unexpected error fetching size info from segment
Unexpected error fetching size info from segment
Unexpected error fetching size info from segment
Total	184	+237607112	29787616	2109088091008

is that expected behaviour? The triple count query also took a lot longer than I remember. This particular graph has just north of 90 million triples in it.

Running a concurrent query was also very slow.

Regards,

Phil.

[Steve Harris]

Yeah, that's not expected - something has gone wrong with your backends.

Possible causes:

out of disk

permissions problems on /var/lib/4store/ indexes (this on came up recently on IRC)

crashes when importing

use of kill -9 on 4s-backends

- Steve

--
You received this message because you are subscribed to the Google Groups "4store-support" group.
To view this discussion on the web visit https://groups.google.com/d/msg/4store-support/-/b5vbywbH_3AJ.
To post to this group, send email to 4store-...@googlegroups.com.
To unsubscribe from this group, send email to 4store-suppor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/4store-support?hl=en.

-- 

Steve Harris, CTO

Garlik, a part of Experian

1-3 Halford Road, Richmond, TW10 6AW, UK

+44 20 8439 8203  http://www.garlik.com/

Registered in England and Wales 653331 VAT # 887 1335 93

Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ

[Philip John]

Hi Steve,

Strange thing is, as soon as the long running select finished what it was doing it all returned to normal and serviced all queries without issue.

I've checked the permissions, and all seems ok there (rw by the user that starts 4s, which is in this case root).

Import was done over HTTP into the 4s-httpd. Never use kill -9 to bring down backend.

Have noticed two segfaults on one of the nodes though (need to check the others):

May 17 21:18:19 -lab-03 kernel: : 4s-backend[10268]: segfault at 7fff4aeb7558 ip 00000000004042d7 sp 00007fff4aeb7560 error 6 in 4s-backend[400000+31000]
May 17 21:18:19 -lab-03 4store[10237]: 4s-server.c:318 kb=pjohn child 10268 terminated by signal 11
May 17 21:18:19 -lab-03 4store[10237]:  1: 4s-backend() [0x417ec3]
May 17 21:18:19 -lab-03 4store[10237]:  2: /lib64/libglib-2.0.so.0() [0x3b4ce370c4]
May 17 21:18:19 -lab-03 4store[10237]:  3: /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x22e) [0x3b4ce38f0e]
May 17 21:18:19 -lab-03 4store[10237]:  4: /lib64/libglib-2.0.so.0() [0x3b4ce3c938]
May 17 21:18:19 -lab-03 4store[10237]:  5: /lib64/libglib-2.0.so.0(g_main_loop_run+0x195) [0x3b4ce3cd55]
May 17 21:18:19 -lab-03 4store[10237]:  6: 4s-backend() [0x418580]
May 17 21:18:19 -lab-03 4store[10237]:  7: 4s-backend() [0x40519c]
May 17 21:18:19 -lab-03 4store[10237]:  8: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3b4b21ecdd]
May 17 21:18:19 -lab-03 4store[10237]:  9: 4s-backend() [0x403c39]
May 17 21:18:20 -lab-03 kernel: : 4s-backend[10269]: segfault at 7fff4aeb3388 ip 00000000004042d7 sp 00007fff4aeb3390 error 6 in 4s-backend[400000+31000]
May 17 21:18:21 -lab-03 4store[10237]: 4s-server.c:318 kb=pjohn child 10269 terminated by signal 11
May 17 21:18:21 -lab-03 4store[10237]:  1: 4s-backend() [0x417ec3]
May 17 21:18:21 -lab-03 4store[10237]:  2: /lib64/libglib-2.0.so.0() [0x3b4ce370c4]
May 17 21:18:21 -lab-03 4store[10237]:  3: /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x22e) [0x3b4ce38f0e]
May 17 21:18:21 -lab-03 4store[10237]:  4: /lib64/libglib-2.0.so.0() [0x3b4ce3c938]
May 17 21:18:21 -lab-03 4store[10237]:  5: /lib64/libglib-2.0.so.0(g_main_loop_run+0x195) [0x3b4ce3cd55]
May 17 21:18:21 -lab-03 4store[10237]:  6: 4s-backend() [0x418580]
May 17 21:18:21 -lab-03 4store[10237]:  7: 4s-backend() [0x40519c]
May 17 21:18:21 -lab-03 4store[10237]:  8: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3b4b21ecdd]
May 17 21:18:21 prim-lab-03 4store[10237]:  9: 4s-backend() [0x403c39]

Regards,

Phil.

[Philip John]

Just checked the other three nodes and all three had a segfault.

Am running the very latest raptor2 and rasqal, so will try downgrading them and see if it makes a difference.

Phil.

[Steve Harris]

If not, could you attach a valgrind or gdb to the backends to try and trap the segfault?

I've been doing a little testing with the latest rasqal and Git HEAD of 4store, but not enough to be confident that it works.

Cheers,

   Steve

[Philip John]

Sure, I'll give that a go later.

I've also downgraded rasqal and raptor2 and still see the segfault when doing a

SELECT (count(?s) as ?count) WHERE { ?s ?p ?o }

Phil.

[Steve Harris]

OK, I definitely can't reproduce that, for what it's worth. So if you can trap the segfault that would be really helpful.

Cheers,

   Steve