search for: thrashing

...thing changed on the server. > > Recently (Jan 27th) some of the Archlinux clients updated from a 4.8.x > kernel to a 4.9.x kernel. Again, things ran fine. Then on Jan 30th > around 2am the Archlinux clients using 4.9.x kernels and utilizing > mount.cifs to access samba shares began thrashing on TCP port 445, > causing high CPU load on the server. These machines now cause > thrashing after 15-20 minutes whenever a share is mounted using > mount.cifs. > > When it's thrashing, I see thousands of opened ports from a single > client: # sockstat -4 | grep 10.0.1.87 | w...

...g fine for a while and nothing changed on the server. Recently (Jan 27th) some of the Archlinux clients updated from a 4.8.x kernel to a 4.9.x kernel. Again, things ran fine. Then on Jan 30th around 2am the Archlinux clients using 4.9.x kernels and utilizing mount.cifs to access samba shares began thrashing on TCP port 445, causing high CPU load on the server. These machines now cause thrashing after 15-20 minutes whenever a share is mounted using mount.cifs. When it's thrashing, I see thousands of opened ports from a single client: # sockstat -4 | grep 10.0.1.87 | wc 10013 70091 740962 An...

On Wed, 8 Feb 2017 20:15:05 -0600 Paul Klapperich via samba <samba at lists.samba.org> wrote: > Well that was easier than I thought. Here's the default config > provided by archlinux's samba package, but with "deadtime = 1" > included. With this config, shares mounted via mount.cifs thrash on > port 445 after a few minutes. I think the reconnect logic in the

Rsync thrashes my buffer cache when transfering large files. I see that some people worked on this problem about a year ago. Did they find a workable solution? I'm getting tired of everything slowing to zero while rsync grinds away. Josh Snyder -------------- next part -------------- HTML attachment scrubbed and removed

At some stage (possibly commit r17268) oggpack_writecopy started to fail with some strings longer than 256 bytes and all strings longer than 512 bytes. Also it thrashes the stack with very long strings. Lithopsian

Sent 12 hours ago and it never showed up (slightly reworded here). Sorry if this is a duplicate: --------------------------------------------- Scenario: a person selects an Auto Attendant option that fires off the Directory application (CVS circa 3/22). Three questions: 1) How do they escape if they didn't mean to go there in the first place (without having to hang up...)? Config of

Hello all, To start off with, I will admit to being very much a samba newbie. Having said that, I set out on Friday to set up what I thought to be a very simple task. I wanted to share a HP inkjet printer off of an old laptop. I spent quite a bit of time on it and finally friday evening, I was able to get things working (I thought). Finally, test pages from all the clients printed

...ver. > > > > Recently (Jan 27th) some of the Archlinux clients updated from a 4.8.x > > kernel to a 4.9.x kernel. Again, things ran fine. Then on Jan 30th > > around 2am the Archlinux clients using 4.9.x kernels and utilizing > > mount.cifs to access samba shares began thrashing on TCP port 445, > > causing high CPU load on the server. These machines now cause > > thrashing after 15-20 minutes whenever a share is mounted using > > mount.cifs. > > > > When it's thrashing, I see thousands of opened ports from a single > > client: # soc...

On 25/11/2014, isdtor <isdtor at gmail.com> wrote: > We recently started upgrading users' workstations to CentOS6. Now > we've come across an interesting issue: > ~user/.local/share/gvfs-metadata is filling up with tons of files. > Once there are around 69270 of them, no more are being created, and > the NetApp filer the user's home is on logs: > > Directory

Does R do its own swapping out to disk? I disabled Linux swapping and the system still gets stuck in Purgatory where there's little CPU activity but the disk goes like crazy. That's with R having almost the whole machine to itself and running a memory hungry compute only function. I've seen this behavior with other version numbers but I'm running R 2.0.0 under Fedora Core 3.

On Wed, 8 Feb 2017 16:43:53 -0600 Paul Klapperich via samba <samba at lists.samba.org> wrote: > Very well. Here is the affected smb.conf. > ------ > [global] > server min protocol = NT1 > server max protocol = SMB3 > interfaces = 127.0.0.1 10.0.0.8 > bind interfaces only = yes > encrypt passwords = yes > dns proxy = no > strict

...some reason, so I'll have to talk to them on that one and it seems they have no option for me to modify the server role. Thankfully I can edit smb.conf directly on the archlinux box where I was able to duplicate the issue. Setting sever role = auto, domain logons = yes doesn't fix the TCP thrashing and works with the SIDs already populated in LDAP. It looks like removing "deadtime = 15" from the smb.conf prevents the TCP thrashing. If I set "deadtime = 1" then the thrashing happens after 3 minutes or so. I'll see if I can put together a conf file that isn't a di...

okey doke. I have read the faq, I have browsed the samba web sites, and I did go through diagnose.txt and the other documentation but still... none of the win95 boxes on my network can see my samba server in the network neighborhood. usage of "net use x: \\server\share" seem to work fine on the client machines though as well as everything else in the diagnose.txt document. Could

>On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote: >> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: >> > Is this really a problem for MLton? I think you only get less precise >> > alias analysis, and that's it. >> >> Correct. However, I want a fair comparison between LLVM performance >> and the native x86

We recently started upgrading users' workstations to CentOS6. Now we've come across an interesting issue: ~user/.local/share/gvfs-metadata is filling up with tons of files. Once there are around 69270 of them, no more are being created, and the NetApp filer the user's home is on logs: Directory ..../user/.local/share/gvfs-metadata/ reached the maxdirsize limit. Reduce the number of

Le 09/09/2017 ? 15:14, Robert Nichols a ?crit : > Every system that runs continuously for more that a few days will have > some pages that were used once when some long-running process started > and were never referenced again. Those pages will eventually migrate out > to swap, and that's the best place for them. Right now, I see that this > system has been up for 16 days and

...being actively used, that if non-resident would cause a large amount of paging. If you shrink the domain down to that number of pages + some padding (x%?), then the system will run happily in a stable state. If that number increases, then the system will need new memory soon, to stop it from thrashing. And if that number goes way below the domain's actual memory allocation, then it has "too much" memory. Is this what "Active" accounts for? Is Active just active usermode/pagecache pages, or does it also include kernel allocations? Presumably Inactive Clean memory ca...

...being actively used, that if non-resident would cause a large amount of paging. If you shrink the domain down to that number of pages + some padding (x%?), then the system will run happily in a stable state. If that number increases, then the system will need new memory soon, to stop it from thrashing. And if that number goes way below the domain's actual memory allocation, then it has "too much" memory. Is this what "Active" accounts for? Is Active just active usermode/pagecache pages, or does it also include kernel allocations? Presumably Inactive Clean memory ca...

...LVMContext, and then put the work of uniquing by accessing the context off of the type. There are obviously some pros and to both approaches. Going back to the old-style increases compatibility with 2.5, and breaks up the massive LLVMContext class. On the downside, it would cause massive thrashing on TOT, because I will have to revert about two weeks worth of commits in widely dispersed parts of the tree, and because a number of clients have already switched to the new TOT API. Any comments and/or opinions on this decision are welcome. --Owen -------------- next part -------------- A n...

...e to talk to them on that > one and it seems they have no option for me to modify the server role. > Thankfully I can edit smb.conf directly on the archlinux box where I was > able to duplicate the issue. > > Setting sever role = auto, domain logons = yes doesn't fix the TCP > thrashing and works with the SIDs already populated in LDAP. > > It looks like removing "deadtime = 15" from the smb.conf prevents the TCP > thrashing. If I set "deadtime = 1" then the thrashing happens after 3 > minutes or so. > > I'll see if I can put together a c...