Re: Things you learn

houghi wrote:

Thanks for the response!

ACE wrote:
Killed IVP6 (browser and system level)- Helped a bit

Perhaps then your provider is an issue.

Could very well be, but if I can make progress locally, it tells me that the
problems are most probably mine. I believe that IPV6 packets proceed IPV4
packets, so the rejection of data must take time.


Turned off firewall - Helped a lot

Strange, as that would only matter if there is an enourmous amount of
traffic. And with enourmous, I am talking about more then your household
connection could handle.

My idea here was to clear the pipe and go from there. Certainly if I am
producing and receiving a lot of packets, turning off the firewall should
make a difference. I guess another question would be if Virtuoso is sending
information out and getting a response? Nast shows me a lot of headers, but
I haven't checked it lately, nor am I really sure what I am looking for.



Went to only DCHP4 - That helped

Also strange as that only matters when the connection is set up.

This is when I was investigating possible conflicts in DNS. Seemed to work,
though I agree its strange.


Then went to investigate CPU and memory. Found that Firefox is taking
161mb of memory, while Chrome looks at each page ass a process and adds
up close to that. CPU cores were both at 100%, very little swap going
on.

Memory is there to be used. 161MB is not that much and as there is no
wap used, it should be considerd normal.

Agree


Then I

Changed the Hardock from default @256 to @512 - this made things a bit
zippyer overall

What is hardock?

This limits the size of the memory that a single process may lock in
physical memory (thus preventing it to be swapped out). The default is set
at 256K. Seemed to make everything work better.


Then I looked at the processes and noticed that Virtuoso was gobbling
CPU. Killed it, and now things are running semi smoothily. As I
understand it, Virtuoso does a lot of indexing control? What is the
best way to fix this problem and how much am I risking for more
trouble?

Read this: https://bbs.archlinux.org/viewtopic.php?id=90756

Interesting. I get this, but how do I do the re-index after? Do I really
need to?

--
Ace
.

Relevant Pages

  • Re: [PATCH 00/28] Swap over NFS -v16
    ... To do so we need to distinguish needed from unneeded packets; ... our state must not consume memory, ... a/ in caches, such as the fragment cache and the route cache ...
    (Linux-Kernel)
  • Re: [PATCH 00/28] Swap over NFS -v16
    ... of dirty memory so that when we desperately need memory on the ... any incoming packets. ... So suppose we forgot about all the allocation tracking (that doesn't ... A packet is received, it can be a fragment, it will be placed in the ...
    (Linux-Kernel)
  • Panic: Kernel page fault with ath0_com_lock held, r211295
    ... Kernel page fault with the following non-sleepable locks held: ... Physical memory: 2031 MB ... Loaded symbols for /boot/kernel/tmpfs.ko ... data packets ...
    (freebsd-current)
  • Re: [PATCH 00/28] Swap over NFS -v16
    ... To do so we need to distinguish needed from unneeded packets; ... our state must not consume memory, ... a/ in caches, such as the fragment cache and the route cache ...
    (Linux-Kernel)
  • [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new Dell BIOS update driver
    ... This also has a fix where the packets were leaked in the function create_packet line#227. ... +The BIOS update is done by writing the new BIOS image in to contiguous physical ... +memory addressable by the BIOS. ... +The disadvantage of contiguous allocation is that it may not be always possible ...
    (Linux-Kernel)