Hi Hugh,
here is the result of the status command on the running instance:
----------
Database Status:
File size 168789278720, 20604160 pages, 6944022 free.
5450000 buffers, 4813858 used, 530 dirty 0 wired down, repl age
26906401 0 w. io 0 w/crsr.
Disk Usage: 14012379 reads avg 0 msec, 0% r 0% w last 0 s, 2349564
writes,
379624 read ahead, batch = 31. Autocompact 986960 in 619187 out,
37% saved col ac: 576044 in 13% saved.
Gate: 623830 2nd in reads, 0 gate write waits, 0 in while read 0 busy
scrap.
Log = /data/virtuoso7/1112/virtuoso.trx, 104765 bytes
13657123 pages have been changed since last backup (in checkpoint state)
Current backup timestamp: 0x0000-0x00-0x00
Last backup date: unknown
Clients: 294 connects, max 1 concurrent
RPC: 3060 calls, -282 pending, 1 max until now, 0 queued, 0 burst reads
(0%), 1 second brk=44965326848
Checkpoint Remap 2000 pages, 0 mapped back. 277 s atomic time.
DB master 20604160 total 6944022 free 2000 remap 4 mapped back
temp 745728 total 745722 free
----------
It can get 128G of memory tops, so I'd expect memory not to be an issue?
I have a related question. Considering also the FTI, what is the best
parameter for log_enable() to load/update several millions triples? And
what is the default setting? My understanding is that 2 or 3 should be
preferred for bulk loads (causing "holes" in the FTI though), while 1 is
the default. Is that right? Do you have any suggestions?
Thanks,
Nicola
Il 28/11/2013 05:27, Hugh Williams ha scritto:
> Hi Nicola,
>
> You can delete and recreate the indexes, which should not be an issue
> provided there is sufficient memory available which will determine how long
> the index recreation will take. How much memory is available on the server
> hosting Virtuoso and what does the "status('');" command return when runs
> against the Virtuoso server from the commandline isql tool ?
>
> The Virtuoso 7 open source updated is scheduled to go out next week ...
>
> Best Regards
> Hugh Williams
> Professional Services
> OpenLink Software, Inc. // http://www.openlinksw.com/
> Weblog -- http://www.openlinksw.com/blogs/
> LinkedIn -- http://www.linkedin.com/company/openlink-software/
> Twitter -- http://twitter.com/OpenLink
> Google+ -- http://plus.google.com/100570109519069333827/
> Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
>
> On 27 Nov 2013, at 14:26, Nicola Vitucci <nicola.vitu...@gmail.com> wrote:
>
>> Hi Hugh,
>>
>> I needed it because I updated quite a lot of data and for doing so I
>> disabled the triggers, so now a search with bif:contains returns too few
>> results. What about deleting the index and recreating it? Would it be
>> feasible with ~2B triples?
>>
>> Anyway, when is the update being scheduled? I might also have a question
>> related to query planning...
>>
>> Thanks,
>>
>> Nicola
>>
>> Il 27/11/2013 14:05, Hugh Williams ha scritto:
>>> Hi Nicola,
>>>
>>> Are you having a specific problem with FT indexes in v7 ? As the
>>> DB.DBA.RDF_OBJ_FT_RECOVER() function issue is known and thus you need the
>>> update to get this fix, there is also a known issue with incremental FT
>>> Indexes which will be in the updated git archive being prepared ...
>>>
>>> Best Regards
>>> Hugh Williams
>>> Professional Services
>>> OpenLink Software, Inc. // http://www.openlinksw.com/
>>> Weblog -- http://www.openlinksw.com/blogs/
>>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>>> Twitter -- http://twitter.com/OpenLink
>>> Google+ -- http://plus.google.com/100570109519069333827/
>>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>>> Universal Data Access, Integration, and Management Technology Providers
>>>
>>> On 27 Nov 2013, at 11:17, Nicola Vitucci <nicola.vitu...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I saw that a call to DB.DBA.RDF_OBJ_FT_RECOVER() returns a known error
>>>> as explained here:
>>>>
>>>> http://boards.openlinksw.com/phpBB3/viewtopic.php?f=12&t=6015
>>>>
>>>> My question is: what is the best alternative to rebuild the full text
>>>> index in the meanwhile?
>>>>
>>>> Thanks,
>>>>
>>>> Nicola
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>>> organizations don't have a clear picture of how application performance
>>>> affects their revenue. With AppDynamics, you get 100% visibility into your
>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>>>> Pro!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Virtuoso-users mailing list
>>>> Virtuoso-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Virtuoso-users mailing list
>> Virtuoso-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
