On Sat, 2024-03-09 at 13:54 +0100, hw wrote:
>
> NFS can be hard on network card drivers
> IPv6 may be faster than IPv4
> the network cable might suck
> the switch might suck or block stuff
As iperf and other network protocols were confirmed to be fast by the
OP it is very unlikely that it is a s
On Thu, 2024-03-07 at 10:13 +0100, Stefan K wrote:
> Hello guys,
>
> I hope someone can help me with my problem.
> Our NFS performance ist very bad, like ~20MB/s, mountoption looks like that:
Reading or writing, or both?
Try testing with files on a different volume.
> rw,relatim
Mike Kupfer wrote:
> Stefan K wrote:
>
> > > Can you partition the files into 2 different shares? Put the database
> > > files in one share and access them using "sync", and put the rest of the
> > > files in a different share, with no "sync"?
> > this could be a solution, but I want to understa
Stefan K wrote:
> > Can you partition the files into 2 different shares? Put the database
> > files in one share and access them using "sync", and put the rest of the
> > files in a different share, with no "sync"?
> this could be a solution, but I want to understand why is it so slow and fix
>
Stefan K wrote:
> > Run the database on the machine that stores the files and perform
> > database access remotely over the net instead. ?
>
> yes, but this doesn't resolve the performance issue with nfs
But it removes your issue that forces you to use the sync option.
> Run the database on the machine that stores the files and perform
> database access remotely over the net instead. ?
yes, but this doesn't resolve the performance issue with nfs
> Can you partition the files into 2 different shares? Put the database
> files in one share and access them using "sync", and put the rest of the
> files in a different share, with no "sync"?
this could be a solution, but I want to understand why is it so slow and fix
that
Stefan K wrote:
> > You could try removing the "sync" option, just as an experiment, to
> > see how much it is contributing to the slowdown.
>
> If I don't use sync I got around 300MB/s (tested with 600MB-file) ..
> that's ok (far from great), but since there are database files on the
> nfs it
> You could try removing the "sync" option, just as an experiment, to see
> how much it is contributing to the slowdown.
If I don't use sync I got around 300MB/s (tested with 600MB-file) .. that's ok
(far from great), but since there are database files on the nfs it can cause
file/database corr
> You could test with noatime if you don't need access times.
> And perhaps with lazytime instead of relatime.
Mountoptions are:
type zfs (rw,xattr,noacl)
I get you point, but when you look at my fio output, the performance is quiet
good
> Could you provide us
> nfsstat -v
server:
nfsstat -v
Serv
On 2024-03-07, Stefan K wrote:
> I hope someone can help me with my problem.
> Our NFS performance ist very bad, like ~20MB/s, mountoption looks like that:
> rw,relatime,sync,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,local_lock=none
Wha
Stefan K wrote:
> 'sync'-mountoption is important (more or less), but it should still be
> much faster than 20MB/s
I don't know if "sync" could be entirely responsible for such a
slowdown, but it's likely at least contributing, particularly if the
application is doing small I/Os at the system cal
Hi Ralph,
I just tested it with scp and I got 262MB/s
So it's not a network issue, just a NFS issue, somehow.
best regards
Stefan
> Gesendet: Donnerstag, 07. März 2024 um 11:22 Uhr
> Von: "Ralph Aichinger"
> An: debian-user@lists.debian.org
> Betreff: Re: very poor
On Thu, 2024-03-07 at 10:13 +0100, Stefan K wrote:
> Hello guys,
>
> I hope someone can help me with my problem.
> Our NFS performance ist very bad, like ~20MB/s, mountoption looks
> like that:
Are both sides agreeing on MTU (using Jumbo frames or not)?
Have you tested the net
Hello guys,
I hope someone can help me with my problem.
Our NFS performance ist very bad, like ~20MB/s, mountoption looks like that:
rw,relatime,sync,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,local_lock=none
The NFS server (debian 12) is a ZFS
Am 2006-03-20 18:05:50, schrieb Pol Hallen:
> Hi all :-)
>
> i'd like known the performance of network file system
>
> i have a debian stable in a server (p4, 1Gb ram. ethernet 10/100) and
> the same
> hardware in the client.
My FileServer is a AMD Sempron 2200+, 256 MB Ram, Intel e1000) and m
On Mon, 20 Mar 2006, Michael Schurter wrote:
> > I use the client for burn my dvd data (with smbmount) but the speed of my
> > dvd
> > is 1,380Kbs :-((( this mean a lot of time per single disc :-(((
put your *.iso image on a local disk on the same system as
your dvd burner
> Better. You wo
Pol Hallen wrote:
Hi all :-)
i'd like known the performance of network file system
i have a debian stable in a server (p4, 1Gb ram. ethernet 10/100) and the same
hardware in the client.
I use the client for burn my dvd data (with smbmount) but the speed of my dvd
is 1,380Kbs :-((( this mea
Hi all :-)
i'd like known the performance of network file system
i have a debian stable in a server (p4, 1Gb ram. ethernet 10/100) and the same
hardware in the client.
I use the client for burn my dvd data (with smbmount) but the speed of my dvd
is 1,380Kbs :-((( this mean a lot of time per s
Thanks for the suggestion. 2.2.10 also has better nfs client performance
-- I just tried it after a few hassles building a .deb to get
dhcp-client-beta to work on a slink system with the 2.2.10 kernel.
user time real time
Hi,
Does anyone have any recommendations on improving nfs client performance
on slink? All of our linux machines are running slink and they all
have poor performance to an HP nfs server. I've heard of some kernel
patches for 2.2.x, but I haven't been able to find out exactly what I
needed with my
21 matches
Mail list logo
