https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/435/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Hi.
I have FreeBSD 10.2-STABLE r289293 (but I have observed this situation
on different releases) and a zfs. I also have one directory that used to
have a lot of (tens of thousands) files. I surely takes a lot of time to
get a listing of it. But now I have 2 files and a couple of dozens
direc
On Thu, Oct 20, 2016 at 3:47 PM, Eugene M. Zheganin wrote:
> Hi.
>
> I have FreeBSD 10.2-STABLE r289293 (but I have observed this situation on
> different releases) and a zfs. I also have one directory that used to have a
> lot of (tens of thousands) files. I surely takes a lot of time to get a
>
Eugene M. Zheganin wrote on 2016/10/20 15:47:
Hi.
I have FreeBSD 10.2-STABLE r289293 (but I have observed this situation
on different releases) and a zfs. I also have one directory that used to
have a lot of (tens of thousands) files. I surely takes a lot of time to
get a listing of it. But now
Have ignored this thread untiul now, but I observed the same behaviour
on mysystems over the last week or so. In my case its an exim spool
directory, which was hugely full as some point (thousands of
files) and now takes an awfully long time to open and list. I delet
and remake them and the problem
Am Donnerstag, 20. Oktober 2016 schrieb Eugene M. Zheganin:
> Hi.
>
> I have FreeBSD 10.2-STABLE r289293 (but I have observed this situation
> on different releases) and a zfs. I also have one directory that used to
> have a lot of (tens of thousands) files. I surely takes a lot of time to
> ge
On Wed, Oct 19, 2016 at 11:10 AM, Slawa Olhovchenkov wrote:
> tcsh called by sshd for invocation of scp: `tcsh -c scp -f Расписание.pdf`
> At this time no any LC_* is set.
> tcsh read .cshrc and set LC_CTYPE=ru_RU.UTF-8 LC_COLLATE=ru_RU.UTF-8.
> After this invocation of scp will be incorrect:
>
>
On Thu, Oct 20, 2016 at 08:54:05AM -0600, Alan Somers wrote:
> On Wed, Oct 19, 2016 at 11:10 AM, Slawa Olhovchenkov wrote:
> > tcsh called by sshd for invocation of scp: `tcsh -c scp -f Расписание.pdf`
> > At this time no any LC_* is set.
> > tcsh read .cshrc and set LC_CTYPE=ru_RU.UTF-8 LC_COLLA
Hi.
On 20.10.2016 18:54, Nicolas Gilles wrote:
Looks like it's not taking up any processing time, so my guess is
the lag probably comes from stalled I/O ... bad disk?
Well, I cannot rule this out completely, but first time I've seen this
lag on this particular server about two months ago, and I
Hi.
On 20.10.2016 19:03, Miroslav Lachman wrote:
What about snapshots? Are there any snapshots on this filesystem?
Nope.
# zfs list -t all
NAMEUSED AVAIL REFER MOUNTPOINT
zroot 245G 201G 1.17G legacy
zroot/tmp 10.1M 201G
Hi,
On 20.10.2016 19:12, Pete French wrote:
Have ignored this thread untiul now, but I observed the same behaviour
on mysystems over the last week or so. In my case its an exim spool
directory, which was hugely full as some point (thousands of
files) and now takes an awfully long time to open an
Hi.
On 20.10.2016 19:18, Dr. Nikolaus Klepp wrote:
I've the same issue, but only if the ZFS resides on a LSI MegaRaid and one
RAID0 for each disk.
Not in my case, both pool disks are attached to the Intel ICH7 SATA300
controller.
Thanks.
Eugene.
__
> > I've the same issue, but only if the ZFS resides on a LSI MegaRaid and one
> > RAID0 for each disk.
> >
> Not in my case, both pool disks are attached to the Intel ICH7 SATA300
> controller.
Nor my case - my discs are on this:
ahci0:
___
freebsd
Do you have atime enabled for the relevant volume?
If so disable it and see if that helps:
zfs set atime=off
Regards
Steve
On 20/10/2016 14:47, Eugene M. Zheganin wrote:
Hi.
I have FreeBSD 10.2-STABLE r289293 (but I have observed this situation
on different releases) and a zfs. I al
On Wed, 19 Oct 2016 16:38:09 -0700, Kevin Oberman wrote:
> On Wed, Oct 19, 2016 at 3:39 PM, Warner Losh wrote:
>
> > On Wed, Oct 19, 2016 at 12:21 PM, Rostislav Krasny
> > wrote:
> > > On Tue, Oct 18, 2016 at 21:57:29 +1100, Ian Smith
> > wrote:
> > >>
> > >> If FreeBSD GPT images (and
https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/436/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Andrea Venturoli wrote:
Hello.
Last week I upgraded a 9.3/amd64 box to 10.3: since then, it crashed and
rebooted at least once every night.
Hi,
I have quite similar issue, crash dumps every night, but then my
stacktrace is different (crashing mostly in cam/scsi/scsi.c), and my
env is also q
Eugene M. Zheganin wrote:
Hi.
I have FreeBSD 10.2-STABLE r289293 (but I have observed this situation
on different releases) and a zfs. I also have one directory that used to
have a lot of (tens of thousands) files. I surely takes a lot of time to
get a listing of it. But now I have 2 files and a
On 21 October 2016 at 09:09, Peter wrote:
[...]
>
> I see this on my pgsql_tmp dirs (where Postgres stores intermediate
> query data that gets too big for mem - usually lots of files) - in
> normal operation these dirs are completely empty, but make heavy disk
> activity (even writing!) when doing
While I have yet to encounter this with PG on ZFS, knock on wood, this
obviously is not an isolated issue and if possible those experiencing it should
do as much investigation as possible and open a PR. This seems like something
I'm going to read about FreeBSD and PG/ZFS over at Hacker News from
On 20/10/2016 22:18, Jonathan Chen wrote:
On 21 October 2016 at 09:09, Peter wrote:
[...]
I see this on my pgsql_tmp dirs (where Postgres stores intermediate
query data that gets too big for mem - usually lots of files) - in
normal operation these dirs are completely empty, but make heavy disk
On 21 October 2016 at 11:27, Steven Hartland wrote:
> On 20/10/2016 22:18, Jonathan Chen wrote:
>>
>> On 21 October 2016 at 09:09, Peter wrote:
>> [...]
>>>
>>> I see this on my pgsql_tmp dirs (where Postgres stores intermediate
>>> query data that gets too big for mem - usually lots of files) -
On 20/10/2016 23:48, Jonathan Chen wrote:
On 21 October 2016 at 11:27, Steven Hartland wrote:
On 20/10/2016 22:18, Jonathan Chen wrote:
On 21 October 2016 at 09:09, Peter wrote:
[...]
I see this on my pgsql_tmp dirs (where Postgres stores intermediate
query data that gets too big for mem -
On 21 October 2016 at 12:56, Steven Hartland wrote:
[...]
> When you see the stalling what does gstat -pd and top -SHz show?
On my dev box:
1:38pm# uname -a
FreeBSD irontree 10.3-STABLE FreeBSD 10.3-STABLE #0 r307401: Mon Oct
17 10:17:22 NZDT 2016 root@irontree:/usr/obj/usr/src/sys/GENERIC
a
Hi.
On 20.10.2016 21:17, Steven Hartland wrote:
Do you have atime enabled for the relevant volume?
I do.
If so disable it and see if that helps:
zfs set atime=off
Nah, it doesn't help at all.
Thanks.
Eugene.
___
freebsd-stable@freebsd.org mailin
In your case there your vdev (ada0) is saturated with writes from postgres.
You should consider more / faster disks.
You might also want to consider enabling lz4 compression on the PG
volume as its works well in IO bound situations.
On 21/10/2016 01:54, Jonathan Chen wrote:
On 21 October 20
On 21/10/2016 04:52, Eugene M. Zheganin wrote:
Hi.
On 20.10.2016 21:17, Steven Hartland wrote:
Do you have atime enabled for the relevant volume?
I do.
If so disable it and see if that helps:
zfs set atime=off
Nah, it doesn't help at all.
As per with Jonathon what does gstat -pd and top
Have you done any ZFS tuning?
Could you try installing ports/sysutils/zfs-stats and posting the output
from "zfs-stats -a". That might point to a bottleneck or poor cache
tuning.
--
Peter Jeremy
signature.asc
Description: PGP signature
On FreeBSD lilith 10.3-STABLE FreeBSD 10.3-STABLE #0 r307694: Fri Oct 21
00:10:20 EDT 2016 root@lilith:/usr/obj/usr/src/sys/GENERIC amd64
In order to install java/openjdk8 and devel/subversion I had to install the
following as packages instead of compiling it from source also make world
also
29 matches
Mail list logo
