-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just tried and didn't help :-(.
Regards,
- --
Saso
Brent Jones wrote:
> On Wed, Jan 6, 2010 at 2:40 PM, Saso Kiselkov wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Buffering the writes in the OS would work for me as well - I've go
On Wed, Jan 6, 2010 at 2:40 PM, Saso Kiselkov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Buffering the writes in the OS would work for me as well - I've got RAM
> to spare. Slowing down rm is perhaps one way to go, but definitely not a
> real solution. On rare occasions I could s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Buffering the writes in the OS would work for me as well - I've got RAM
to spare. Slowing down rm is perhaps one way to go, but definitely not a
real solution. On rare occasions I could still get lockups, leading to
screwed up recordings and if its one
On Wed, 6 Jan 2010, Saso Kiselkov wrote:
I'm aware of the theory and realize that deleting stuff requires writes.
I'm also running on the latest b130 and write stuff to disk in large
128k chunks. The thing I was wondering about is whether there is a
mechanism that might lower the I/O scheduling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm aware of the theory and realize that deleting stuff requires writes.
I'm also running on the latest b130 and write stuff to disk in large
128k chunks. The thing I was wondering about is whether there is a
mechanism that might lower the I/O schedul
On Wed, 6 Jan 2010, Saso Kiselkov wrote:
I've encountered a new problem on the opposite end of my app - the
write() calls to disk sometimes block for a terribly long time (5-10
seconds) when I start deleting stuff on the filesystem where my recorder
processes are writing. Looking at iostat I can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've encountered a new problem on the opposite end of my app - the
write() calls to disk sometimes block for a terribly long time (5-10
seconds) when I start deleting stuff on the filesystem where my recorder
processes are writing. Looking at iostat I
Tim Cook writes:
> On Sun, Dec 27, 2009 at 6:43 PM, Bob Friesenhahn <
> bfrie...@simple.dallas.tx.us> wrote:
>
> > On Sun, 27 Dec 2009, Tim Cook wrote:
> >
> >>
> >> That is ONLY true when there's significant free space available/a fresh
> >> pool. Once those files have been deleted and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Be sure to also update to the latest dev b130 release, as that also
helps with a more smooth scheduling class for the zfs threads. If the
upgrade breaks anything, you can always just boot back into the old
environment before the upgrade.
Regards,
- --
Thanks for this thread! I was just coming here to discuss this very same
problem. I'm running 2009.06 on a Q6600 with 8GB of RAM. I have a Windows
system writing multiple OTA HD video streams via CIFS to the 2009.06 system
running Samba.
I then have multiple clients reading back other HD vid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I figured out that apparently I was the idiot in this story, again.
I forgot to set SO_RCVBUF on my network sockets higher, so that's why I
was dropping input packets.
The zfs_txg_timeout=1 flag is still necessary (or else dropping occurs
when com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I tried removing the flow and subjectively packet loss occurs a bit less
often, but still it is happening. Right now I'm trying to figure out of
it's due to the load on the server or not - I've left only about 15
concurrent recording instances, produci
25
To: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] ZFS write bursts cause short app stalls
I progressed with testing a bit further and found that I was hitting
another scheduling bottleneck - the network. While the write burst was
running and ZFS was commiting data to disk, the server wa
Le 28 déc. 09 à 00:59, Tim Cook a écrit :
On Sun, Dec 27, 2009 at 1:38 PM, Roch Bourbonnais > wrote:
Le 26 déc. 09 à 04:47, Tim Cook a écrit :
On Fri, Dec 25, 2009 at 11:57 AM, Saso Kiselkov
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've started porting a video streaming
On Sun, 27 Dec 2009, Tim Cook wrote:
Cmon, saying "all I did was change code and firmware" isn't a valid comparison
at all. Ignoring
that, I'm still referring to multiple streams which create random I/O to the
backend disk.
I do agree with you that this is a problematic scenario. The issue
iscuss@opensolaris.org
> Subject: Re: [zfs-discuss] ZFS write bursts cause short app stalls
>
> I progressed with testing a bit further and found that I was hitting
> another scheduling bottleneck - the network. While the write burst was
> running and ZFS was commiting data to dis
: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] ZFS write bursts cause short app stalls
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I progressed with testing a bit further and found that I was hitting
another scheduling bottleneck - the network. While the write burst was
running and ZFS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I progressed with testing a bit further and found that I was hitting
another scheduling bottleneck - the network. While the write burst was
running and ZFS was commiting data to disk, the server was dropping
incomming UDP packets ("netstat -s | grep ud
On Sun, Dec 27, 2009 at 8:40 PM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Sun, 27 Dec 2009, Tim Cook wrote:
>
> How is that going to prevent blocks being spread all over the disk when
>> you've got files several GB in size being written concurrently and deleted
>> at random? A
On Sun, 27 Dec 2009, Tim Cook wrote:
How is that going to prevent blocks being spread all over the disk
when you've got files several GB in size being written concurrently
and deleted at random? And then throw in a mix of small files as
well, kiss that goodbye.
There would certainly be bloc
On Sun, Dec 27, 2009 at 6:43 PM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Sun, 27 Dec 2009, Tim Cook wrote:
>
>>
>> That is ONLY true when there's significant free space available/a fresh
>> pool. Once those files have been deleted and the blocks put back into the
>> free pool,
On Sun, 27 Dec 2009, Tim Cook wrote:
That is ONLY true when there's significant free space available/a
fresh pool. Once those files have been deleted and the blocks put
back into the free pool, they're no longer "sequential" on disk,
they're all over the disk. So it makes a VERY big differe
On Sun, Dec 27, 2009 at 1:38 PM, Roch Bourbonnais
wrote:
>
> Le 26 déc. 09 à 04:47, Tim Cook a écrit :
>
>
>>
>> On Fri, Dec 25, 2009 at 11:57 AM, Saso Kiselkov
>> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I've started porting a video streaming application to opensolaris on
Le 26 déc. 09 à 04:47, Tim Cook a écrit :
On Fri, Dec 25, 2009 at 11:57 AM, Saso Kiselkov
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've started porting a video streaming application to opensolaris on
ZFS, and am hitting some pretty weird performance issues. The thing
I'm
t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for the mdb syntax - I wasn't sure how to set it using mdb at
runtime, which is why I used /etc/system. I was quite intrigued to find
out that the Solaris kernel was in fact designed for being tuned at
runtime using some generic debugging mechan
On 26/12/2009 12:22, Saso Kiselkov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you, the post you mentioned helped me move a bit forward. I tried
putting:
zfs:zfs_txg_timeout = 1
btw: you can tune it on a live system without a need to do reboots.
mi...@r600:~# echo zfs_txg_timeo
On 12/26/2009 10:41 AM, Saso Kiselkov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Would an upgrade to the development repository of 2010.02 do the same?
I'd like to avoid having to do a complete reinstall, since I've got
quite a bit of custom software in the system already in various pl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for the advice. I did an in-place upgrade to the latest
development b130 release and it seems that the change in scheduling
classes for the kernel writer threads worked (not even having to fiddle
around with logbias) - now I'm just getting small
On Dec 26, 2009, at 1:10 AM, Saso Kiselkov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brent Jones wrote:
On Fri, Dec 25, 2009 at 9:56 PM, Tim Cook wrote:
On Fri, Dec 25, 2009 at 11:43 PM, Brent Jones
wrote:
Hang on... if you've got 77 concurrent threads going, I don't
se
On 12/26/09 09:53, Brent Jones wrote:
On Fri, Dec 25, 2009 at 9:56 PM, Tim Cook wrote:
On Fri, Dec 25, 2009 at 11:43 PM, Brent Jones wrote:
Hang on... if you've got 77 concurrent threads going, I don't see how
that's
a "sequential" I/O load. To the backend storage it's going to look
On Fri, 25 Dec 2009, Saso Kiselkov wrote:
sometimes even longer. I figured that I might be able to resolve this by
lowering the txg timeout to something like 1-2 seconds (I need ZFS to
write as soon as data arrives, since it will likely never be
overwritten), but I couldn't find any tunable param
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you, the post you mentioned helped me move a bit forward. I tried
putting:
zfs:zfs_txg_timeout = 1
in /etc/system and now I'm getting much more even write load (a burst
every 5 seconds), which now does not cause any significant poll()
stalling
On Sat, Dec 26, 2009 at 4:10 PM, Saso Kiselkov wrote:
>> I'm still trying to find the case number I have open with Sunsolve or
>> whatever, it was for exactly this issue, and I believe the fix was to
>> add dozens more "classes" to the scheduler, to allow more fair disk
>> I/O and overall "nicenes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brent Jones wrote:
> On Fri, Dec 25, 2009 at 9:56 PM, Tim Cook wrote:
>>
>> On Fri, Dec 25, 2009 at 11:43 PM, Brent Jones wrote:
>
Hang on... if you've got 77 concurrent threads going, I don't see how
that's
a "sequential" I/O
On Fri, Dec 25, 2009 at 9:56 PM, Tim Cook wrote:
>
>
> On Fri, Dec 25, 2009 at 11:43 PM, Brent Jones wrote:
>>
>> >>
>> >>
>> >
>> >
>> > Hang on... if you've got 77 concurrent threads going, I don't see how
>> > that's
>> > a "sequential" I/O load. To the backend storage it's going to look like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Would an upgrade to the development repository of 2010.02 do the same?
I'd like to avoid having to do a complete reinstall, since I've got
quite a bit of custom software in the system already in various places
and recompiling and fine-tuning would take
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The application I'm working on is a kind of large-scale network-PVR
system for our IPTV services. It records all running TV channels in a
X-hour carrousel (typically 24 or 48-hours), retaining only those bits
which users have marked as being interestin
Try b130.
http://genunix.org/
Cheers,
LK
On 12/26/2009 12:59 AM, Saso Kiselkov wrote:
Hi,
I tried it and I got the following error message:
# zfs set logbias=throughput content
cannot set property for 'content': invalid property 'logbias'
Is it because I'm running some older version which d
On Fri, Dec 25, 2009 at 11:43 PM, Brent Jones wrote:
>
> >>
> >>
> >
> >
> > Hang on... if you've got 77 concurrent threads going, I don't see how
> that's
> > a "sequential" I/O load. To the backend storage it's going to look like
> the
> > equivalent of random I/O. I'd also be surprised to se
On Fri, Dec 25, 2009 at 7:47 PM, Tim Cook wrote:
>
>
> On Fri, Dec 25, 2009 at 11:57 AM, Saso Kiselkov wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I've started porting a video streaming application to opensolaris on
>> ZFS, and am hitting some pretty weird performance issu
On Fri, Dec 25, 2009 at 11:57 AM, Saso Kiselkov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I've started porting a video streaming application to opensolaris on
> ZFS, and am hitting some pretty weird performance issues. The thing I'm
> trying to do is run 77 concurrent video cap
Hi,
I tried it and I got the following error message:
# zfs set logbias=throughput content
cannot set property for 'content': invalid property 'logbias'
Is it because I'm running some older version which does not have this
feature? (2009.06)
Regards,
--
Saso
Leonid Kogan wrote:
> Hi there,
> T
Hi,
I'm not sure what "b130" means, I'm fairly new to OpenSolaris. How do I
find out?
As for the OS version, it is OpenSolaris 2009.06.
Regards,
--
Saso
Richard Elling wrote:
> On Dec 25, 2009, at 9:57 AM, Saso Kiselkov wrote:
>
> I've started porting a video streaming application to opensolaris
Hi there,
Try to:
zfs set logbias=throughput
Good luck,
LK
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Dec 25, 2009, at 9:57 AM, Saso Kiselkov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've started porting a video streaming application to opensolaris on
ZFS, and am hitting some pretty weird performance issues. The thing
I'm
trying to do is run 77 concurrent video capture process
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've started porting a video streaming application to opensolaris on
ZFS, and am hitting some pretty weird performance issues. The thing I'm
trying to do is run 77 concurrent video capture processes (roughly
430Mbit/s in total) all writing into separat
46 matches
Mail list logo
