BaseX-Talk

basex-talk@mailman.uni-konstanz.de

9 participants
5241 discussions

Re: [basex-talk] WG: JAVA Performance Issue under RH8 by using BASEX with NFS system
by Christian Grün 16 Nov '23

16 Nov '23

Hi Andre, It’s probably out of scope to give a reasonable response to your questions via the public mailing list (feel free to ask for our commercial services), but here’s a quick shot: > > - why is the whole database read even for a "small" query ? (looks > like a missing index or bad execution plan.. ?) > > It may depend a lot on what the query does. Could you give us an example for a typical “small query”? > > - The UNIX related question (maybe it's worth opening a ticket with > redhat) > > I guess so. I’m sorry I have no in-depth knowledge on why RHL 6 and 8 behaves differently here. Have you already tried different JDK versions/distributions? Best, Christian

1 0

Re: [basex-talk] WG: JAVA Performance Issue under RH8 by using BASEX with NFS system
by Gerbatsch, Andre 16 Nov '23

16 Nov '23

bounced by the List, re-sent after subscription -- Hello Christian and team, I am from IT and helped Michael to analyze and reproduce the problem. I would like to describe what we found and maybe you have some Ideas what we can optimize. Any advice will be helpful 🙂 The questions are: * why is the whole database read even for a "small" query ? (looks like a missing index or bad execution plan.. ?) * are there some tricks / best practices to optimize ? * why do we use 4K blocksize performing a seek() before every read even for sequential reads from the database file ? * can the blocksize be changed ? does it make sense ? The UNIX related question (maybe it's worth opening a ticket with redhat) * why does the UNIX kernel enforce nfs reads (slow) for the combination: set read lock; seek; read; ... and uses the cache (is fast) if we omit seek() even if the file is locked? Thank you for your comments in advance! Andre ============================ Below are more details. We performed a query (wget output about 150K) and saw in the strace the typical sequence: * open (..tbl.basex) * set read lock * seek(); read() the whole file (650MB) by 4k blocks, seek() before every read (even for sequential read - where the position is already at the right place for the next read()); * close(). We found that all recent OS (RHEL7,8; debian12) are reproducible bypassing the filesystem cache if the database files on a nfs mounted filesystem. RHEL6 uses the filesystem cache. ======================= trace snippets open(.. tbl.basex); fcntl(f, F_SETLK, {l_type=F_RDLCK}; seek(); read(f, 4k); seek(); read(.. 4k); close .. openat(AT_FDCWD</home/drslaanstg/BaseX853_dev/basex/bin>, "/proj/mpi_la/sb_dev/sbof/tbl.basex", O_RDWR|O_CREAT, 0666) = 51 #-- set read lock on the whole file (l_len=0). fcntl(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0 #-- lseek(), read(..,4K), lseek(), read(..,4k) - # reading .. 13:09:30.050965 lseek(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, 0, SEEK_SET) = 0 <0.000063> 13:09:30.051900 read(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, "\0\0\0\0\0\0\0\0\0\0\314b\0\0\0\0001\0\1\0\0\0\0\1\0\0\314a\0\0\0\1"..., 4096) = 4096 <0.179836> 13:09:30.231893 lseek(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, 4096, SEEK_SET) = 4096 <0.000017> 13:09:30.232818 read(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, "\2\0\0\0\0\0\5\274\0\0\0\1\0\0\1\0\t\0004\0\0\0\0\5\0\0\0\2\0\0\1\1"..., 4096) = 4096 <0.000041> 13:09:30.232923 lseek(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, 8192, SEEK_SET) = 8192 <0.000015> 13:09:30.232988 read(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, "\2\0\0@\0\0\n\303\0\0\0\1\0\0\2\0\t\09\0\0\0\0\6\0\0\0\2\0\0\2\1"..., 4096) = 4096 <0.000016> .. #jump to the end and back.. 13:09:30.248343 lseek(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, 192512, SEEK_SET) = 192512 <0.000015> 13:09:30.248416 read(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, "\2\0\0@\0\0\250\n\0\0\0\1\0\0/\0\t\0A\0\0\0\0\25\0\0\0\2\0\0/\1"..., 4096) = 4096 <0.0 13:09:30.248488 lseek(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, 586047488, SEEK_SET) = 586047488 <0.000015> 13:09:30.248567 read(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, "\31\0j\0\0\0/\377\0\0\0(\0\0/\326\v\0\6\0\0\0 \217\0\0\0\0\0\0/\327"..., 4096) = 4096 13:09:30.249898 lseek(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, 196608, SEEK_SET) = 196608 <0.000016> 13:09:30.250564 read(51</proj/mpi_la/sb_dev/sbof/tbl.basex>, "\2\0\0\0\0\0\253\254\0\0\0\1\0\0000\0\t\08\0\0\0\0\3\0\0\0\2\0\0000\1"..., 4096) = 409 close(51) ======== test program to repoduce the behavior. #!/tool/pandora64/bin/python3-latest # test emulating the bad performance when baseX opens a database for read # # both conditions must be true: # 1. set a read lock on the file # 2. seek before reading. # # without lock or without seek it is fast. # # rhel6 - fast (<1s) # rhel7,8 and debian12 - slow (~10s) # nfs -o vers=3,nolock - has no effect # # agerbats (Andre Gerbatsch), 11/10/2023 ############# import fcntl BS= 4096 FN= "/proj/sysadmin_scratch/agerbats/tbl.basex" f = open(FN, "rb", buffering=0) #-- set a read lock fcntl.lockf(f, fcntl.LOCK_SH) f.seek(0,2) file_length=f.tell() offset = 0 while offset < file_length: #-- seek to the next 4k position (it is semantically a noop) f.seek(offset) block=f.read(BS) offset+= BS f.close() -- Andre ________________________________ Von: Otto, Michael (Layout Analysis) <Michael.Otto(a)globalfoundries.com> Gesendet: Montag, 13. November 2023 18:19 An: Gerbatsch, Andre <Andre.Gerbatsch(a)globalfoundries.com> Betreff: WG: [basex-talk] WG: JAVA Performance Issue under RH8 by using BASEX with NFS system ________________________________ Von: Christian Grün <christian.gruen(a)gmail.com> Gesendet: Montag, 13. November 2023 16:11 An: Otto, Michael (Layout Analysis) <Michael.Otto(a)globalfoundries.com> Cc: basex-talk(a)mailman.uni-konstanz.de <basex-talk(a)mailman.uni-konstanz.de> Betreff: Re: [basex-talk] WG: JAVA Performance Issue under RH8 by using BASEX with NFS system 🛑CAUTION: This email originated outside of the GF organization. Please consider the source / sender to ensure the content is safe before clicking on links or opening attachments. If you're unsure, please report this email as phishing so it can be analyzed. …difficult to tell what might be the reason; we didn’t get similar reports so far. Most of the BaseX caching algorithms rely on the file system, but we don’t differ between Windows- and UNIX-based systems. Does it make a difference if you change another JDK distribution? Best, Christian On Mon, Nov 13, 2023 at 12:32 PM Otto, Michael (Layout Analysis) <Michael.Otto(a)globalfoundries.com<mailto:Michael.Otto@globalfoundries.com>> wrote: ________________________________ Von: Otto, Michael (Layout Analysis) <Michael.Otto(a)globalfoundries.com<mailto:Michael.Otto@globalfoundries.com>> Gesendet: Sonntag, 12. November 2023 17:16 An: basex-talk-request(a)mailman.uni-konstanz.de<mailto:basex-talk-request@mailman.uni-konstanz.de> <basex-talk-request(a)mailman.uni-konstanz.de<mailto:basex-talk-request@mailman.uni-konstanz.de>> Betreff: AW: JAVA Performance Issue under RH8 by using BASEX with NFS system Hello. Since switching basex (853) application from RH6 to RH8 I do see a performance issue. internal tests: RH6/NFS --> runtime < 1s RH8/local storage on server --> runtime < 1s RH8/NFS --> runtime > 15s It seams that we see a caching issue in RH8 context (1st read of RH6 taes longer too). I did several tests with several JAVA and BASEX(V10.7) versions (including latest one). IT tried several mounting options for RH8 server to NFS too, but that did not solve that issue. I that a known issue? I guess this is a caching issue of RH8 (actual only seen by using BaseX). Is there any known solution for this? BR GLOBALFOUNDRIES Dresden Module One LLC & Co. KG: Michael Otto Tapeout Engn FAB 1 TAPE OUT INTEGRATION T +49 (0) 351 277-86013 F +49 (0) 351 277-86013 M/S: I21-MPI michael.otto(a)globalfoundries.com<mailto:michael.otto@globalfoundries.com> http://www.globalfoundries.com/ GLOBALFOUNDRIES Dresden Module One Limited Liability Company & Co. KG Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registered Office/ Sitz Dresden I Registergericht Dresden HRA 5255 General Partner/ Vertretungsberechtigter Komplementär: GLOBALFOUNDRIES Dresden Module One LLC (Sitz Wilmington, Delaware, USA) General Manager/ Geschäftsführer der GLOBALFOUNDRIES Dresden Module One LLC: Thomas Caulfield ________________________________ Von: Otto, Michael (Layout Analysis) <Michael.Otto(a)globalfoundries.com<mailto:Michael.Otto@globalfoundries.com>> Gesendet: Mittwoch, 8. November 2023 12:01 An: basex-talk-request(a)mailman.uni-konstanz.de<mailto:basex-talk-request@mailman.uni-konstanz.de> <basex-talk-request(a)mailman.uni-konstanz.de<mailto:basex-talk-request@mailman.uni-konstanz.de>> Betreff: JAVA Performance Issue under RH8 by using BASEX with NFS system Hello. Since switching basex (853) application from RH6 to RH8 I do see a performance issue. internal tests: RH6/NFS --> runtime < 1s RH8/local storage on server --> runtime < 1s RH8/NFS --> runtime > 15s It seams that we see a caching issue in RH8 context (1st read of RH6 taes longer too). I did several tests with several JAVA and BASEX(V10.7) versions (including latest one). IT tried several mounting options for RH8 server to NFS too, but that did not solve that issue. I that a known issue? I guess this is a caching issue of RH8 (actual only seen by using BaseX). Is there any known solution for this? BR GLOBALFOUNDRIES Dresden Module One LLC & Co. KG: Michael Otto Tapeout Engn FAB 1 TAPE OUT INTEGRATION T +49 (0) 351 277-86013 F +49 (0) 351 277-86013 M/S: I21-MPI michael.otto(a)globalfoundries.com<mailto:michael.otto@globalfoundries.com> http://www.globalfoundries.com/ GLOBALFOUNDRIES Dresden Module One Limited Liability Company & Co. KG Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registered Office/ Sitz Dresden I Registergericht Dresden HRA 5255 General Partner/ Vertretungsberechtigter Komplementär: GLOBALFOUNDRIES Dresden Module One LLC (Sitz Wilmington, Delaware, USA) General Manager/ Geschäftsführer der GLOBALFOUNDRIES Dresden Module One LLC: Thomas Caulfield

1 0

WG: JAVA Performance Issue under RH8 by using BASEX with NFS system
by Otto, Michael (Layout Analysis) 13 Nov '23

13 Nov '23

________________________________ Von: Otto, Michael (Layout Analysis) <Michael.Otto(a)globalfoundries.com> Gesendet: Sonntag, 12. November 2023 17:16 An: basex-talk-request(a)mailman.uni-konstanz.de <basex-talk-request(a)mailman.uni-konstanz.de> Betreff: AW: JAVA Performance Issue under RH8 by using BASEX with NFS system Hello. Since switching basex (853) application from RH6 to RH8 I do see a performance issue. internal tests: RH6/NFS --> runtime < 1s RH8/local storage on server --> runtime < 1s RH8/NFS --> runtime > 15s It seams that we see a caching issue in RH8 context (1st read of RH6 taes longer too). I did several tests with several JAVA and BASEX(V10.7) versions (including latest one). IT tried several mounting options for RH8 server to NFS too, but that did not solve that issue. I that a known issue? I guess this is a caching issue of RH8 (actual only seen by using BaseX). Is there any known solution for this? BR GLOBALFOUNDRIES Dresden Module One LLC & Co. KG: Michael Otto Tapeout Engn FAB 1 TAPE OUT INTEGRATION T +49 (0) 351 277-86013 F +49 (0) 351 277-86013 M/S: I21-MPI michael.otto(a)globalfoundries.com http://www.globalfoundries.com/ GLOBALFOUNDRIES Dresden Module One Limited Liability Company & Co. KG Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registered Office/ Sitz Dresden I Registergericht Dresden HRA 5255 General Partner/ Vertretungsberechtigter Komplementär: GLOBALFOUNDRIES Dresden Module One LLC (Sitz Wilmington, Delaware, USA) General Manager/ Geschäftsführer der GLOBALFOUNDRIES Dresden Module One LLC: Thomas Caulfield ________________________________ Von: Otto, Michael (Layout Analysis) <Michael.Otto(a)globalfoundries.com> Gesendet: Mittwoch, 8. November 2023 12:01 An: basex-talk-request(a)mailman.uni-konstanz.de <basex-talk-request(a)mailman.uni-konstanz.de> Betreff: JAVA Performance Issue under RH8 by using BASEX with NFS system Hello. Since switching basex (853) application from RH6 to RH8 I do see a performance issue. internal tests: RH6/NFS --> runtime < 1s RH8/local storage on server --> runtime < 1s RH8/NFS --> runtime > 15s It seams that we see a caching issue in RH8 context (1st read of RH6 taes longer too). I did several tests with several JAVA and BASEX(V10.7) versions (including latest one). IT tried several mounting options for RH8 server to NFS too, but that did not solve that issue. I that a known issue? I guess this is a caching issue of RH8 (actual only seen by using BaseX). Is there any known solution for this? BR GLOBALFOUNDRIES Dresden Module One LLC & Co. KG: Michael Otto Tapeout Engn FAB 1 TAPE OUT INTEGRATION T +49 (0) 351 277-86013 F +49 (0) 351 277-86013 M/S: I21-MPI michael.otto(a)globalfoundries.com http://www.globalfoundries.com/ GLOBALFOUNDRIES Dresden Module One Limited Liability Company & Co. KG Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registered Office/ Sitz Dresden I Registergericht Dresden HRA 5255 General Partner/ Vertretungsberechtigter Komplementär: GLOBALFOUNDRIES Dresden Module One LLC (Sitz Wilmington, Delaware, USA) General Manager/ Geschäftsführer der GLOBALFOUNDRIES Dresden Module One LLC: Thomas Caulfield

2 1

Crash on ADD file.xml
by Csaba Fekete 12 Nov '23

12 Nov '23

Hi all Scenario: I am trying to add a file *while a query is being run through the rest api*. Everything is working fine if no query is being run. Am I trying to do something that isn't supported? The command is: /opt/basex/bin/basex -v -c"OPEN dbname;ADD $fname.xml" The command exits with the message: Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk(a)mailman.uni-konstanz.de Version: BaseX 11.0 beta Java: Ubuntu, 11.0.20.1 OS: Linux, amd64 Stack Trace: java.lang.RuntimeException: dbname: lock file does not exist. at org.basex.util.Util.notExpected(Util.java:68) at org.basex.data.DiskData.finishUpdate(DiskData.java:246) at org.basex.core.cmd.ACreate.update(ACreate.java:97) at org.basex.core.cmd.Add.run(Add.java:56) at org.basex.core.Command.run(Command.java:233) at org.basex.core.Command.execute(Command.java:93) at org.basex.api.client.LocalSession.execute(LocalSession.java:131) at org.basex.api.client.Session.execute(Session.java:36) at org.basex.core.CLI.execute(CLI.java:94) at org.basex.core.CLI.execute(CLI.java:78) at org.basex.core.CLI.execute(CLI.java:65) at org.basex.BaseX.<init>(BaseX.java:82) at org.basex.BaseX.main(BaseX.java:44) Thanks as always Csaba

2 2

Passing an array to REST HTTP service
by Csaba Fekete 03 Nov '23

03 Nov '23

Hi I'm wondering if this is at all possible... I defined an array variable in my XQUERY: declare variable $ca as array(xs:integer) external := []; How can I assign a value (e.g [1,2]) to this variable through the URL? I have already tried: http://host:port/rest/dbname?run=query.xq&$ca[]=1&$ca[]=2 That didn't work. Neither did this: http://host:port/rest/dbname?run=query.xq&$ca=1,2 Any hints are much appreciated. Thanks Csaba

3 3

Text index on uncommon node
by Matthew Dziuban 30 Oct '23

30 Oct '23

Hi all, I'm working with a database structured like so: <data> <element>...</element> <element>...</element> <element>...</element> </data> There are a total of about 1.5 million <element> nodes in the database. Each <element> has many child nodes, one of which is uncommon -- it only appears in 727 <element>s. I'm writing a query that has a condition on this uncommon field, but the query takes about 20 seconds to run, whereas another with a condition on a child node that appears in every <element> only takes about 20 milliseconds to run. Based on the Info in the GUI, it does appear that the text index is being used -- I see 'apply text index for "..."'. Is it expected that the query time would be this much longer? Is the text index somehow built differently for nodes that don't appear often in the database? Thanks in advance, Matt

2 4

RESTXQ Custom Multipart Response
by Jean-Marc ANSEL 29 Oct '23

29 Oct '23

Hello, I'm trying to do a custom multipart response with basex RESTXQ module. The Custom Response paragraph of https://docs.basex.org/wiki/RESTXQ indicates : Custom responses can be generated in XQuery by returning an |rest:response| element, an |http:response| child node that matches the syntax of the EXPath HTTP Client Module <http://expath.org/spec/http-client> specification, and optional child nodes that will be serialized as usual. So, the §4.1 of http://expath.org/spec/http-client (EXPath HTTP Client Module <http://expath.org/spec/http-client>) indicates : <http:response status = integer message = string> (http:header*, (http:multipart | http:body)?) </http:response> But when I try : declare %rest:path('media4') function page:testjm4() { <rest:response> <http:response status="200" message="OK"> <http:header name="Content-Length" value="100"/> <http:body media-type="text"> TEST </http:body> </http:response> </rest:response>}; The answer is irremediably : Stopped at /root/basex/webapp/test.xqm, 46/39: [basex:restxq] Unexpected node: <http:body xmlns:http="http://expath.org/ns/http-client" media-type="text">
TEST 
</http:body> Neither hhtp:body or http:multipart element can be placed as a child of http:response, that seems contradictory with the expath.org spec... Any help would be appreciated... Thanks o lot! JM Using : BaseX Version 10.7 httpserver : basexhttp Operating System: Ubuntu 18.04.6 LTS Kernel: Linux 4.15.0-197-generic Architecture: x86-64

2 1

Db:token() vs db:attribute(): Attribute is much slower -- why
by Eliot Kimber 26 Oct '23

26 Oct '23

Using 10.6 on macOS: I have a data file with elements like: <record language="en-US" family="pce-test-data" bundlename="bundle-appportman-application-portfolio-management" topicpath="product/application-portfolio-management/concept/application-portfolio-management-landing-page.dita" notviewed="viewed" viewcount="13579"> One such entry for each topic in our public docs server that is accessed at least once (Adobe page views data). I generate a report for all the topics used from a root map that includes the page views data for each topic for which there is an entry. The database with this data set is indexed with an attribute and a token index. In my testing I’m finding that lookup using db:attribute() on the @topicpath attribute (which is always a single value) is about 10x slower than using db:token(). That is, I have this code: $records := db:token($analyticsmgmt:analyticsDatabase, $docPath, 'topicpath')/.. When I run this for a set of about 1200 topics, the db:token version takes about 400ms but the db:attribute version takes 9 seconds! I’m surprised at this result—I would expect the two forms of index to perform with the same speed: the attribute is a single blank-delimited token and I would expect the string match under the covers to be using the same code path. But using the db:token database is clearly faster by a lot. If I report the time each lookup uses, the times vary quite a lot, but for the token lookup they tend to be in the 10-60ms range, but for the attribute lookup, many are in the 1 or 2 second range, which explains the much longer run time. I’m wondering if this result is expected due to implementation details of the attribute index as distinct from the token index or if this indicates some logic bug in the attribute index implementation. Cheers, E. _____________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 servicenow.com<https://www.servicenow.com> LinkedIn<https://www.linkedin.com/company/servicenow> | Twitter<https://twitter.com/servicenow> | YouTube<https://www.youtube.com/user/servicenowinc> | Facebook<https://www.facebook.com/servicenow>

2 4

Crash when starting basexgui
by Joe Wicentowski 24 Oct '23

24 Oct '23

Hi all, I am experiencing a crash when starting basexgui. The splash screen appears briefly, and then the message pasted in below appears, and I've also attached the referenced error report file and the crash report that appears in the Mac crash dialog. I'm using BaseX 10.7, installed via Homebrew (which installed BaseX's openjdk dependency and thus is using openjdk 21), on macOS Sonoma (14.0). I'd be happy to provide any other info that would help in identifying the cause of the crash. Joe % basexgui 2023-10-24 07:34:22.308 java[69449:3862142] WARNING: Secure coding is automatically enabled for restorable state! However, not on all supported macOS versions of this application. Opt-in to secure coding explicitly by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState:. # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x00007ff80d2b1b73, pid=69449, tid=259 # # JRE version: OpenJDK Runtime Environment Homebrew (21.0) (build 21) # Java VM: OpenJDK 64-Bit Server VM Homebrew (21, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64) # Problematic frame: # C [AppKit+0xc8fb73] _NSCarbonMenuCrashIfNeeded+0x258 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/joe/workspace/hsg-project/repos/hsg-shell/hs_err_pid69449.log # # If you would like to submit a bug report, please visit: # https://github.com/Homebrew/homebrew-core/issues # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # zsh: abort basexgui

1 0

New escape-solidus option
by Thompson, Timothy 23 Oct '23

23 Oct '23

Hello, I was very happy to see that a new escape-solidus option had been defined for XQuery/XPath 4.0. Is this available in the latest BaseX snapshot? I tried this: <fn:map> <fn:string key="Escape/Solidus">Test</fn:string> </fn:map> => serialize(map {"method": "json", "json": map {"format": "basic", "escape-solidus": "no"}}) But it returns: {"Escape\/Solidus":"Test"} Thank you, Tim -- Tim A. Thompson (he, him) Librarian for Applied Metadata Research Yale University Library

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

BaseX-Talk