On 1/12/17 12:04 AM, Руслан Закиров wrote:
> Looks like BSD 11 has improvements in this area. At least `man` says
> that sendfile doesn't block on disk I/O and can return earlier with
> success.
That's correct observation.
https://www.nginx.com/blog/nginx-and-netflix-contribute-new-sendfile2-to-f
On Wed, Jan 11, 2017 at 10:25 PM, Руслан Закиров wrote:
>
> On amd64 sendfile() uses mbufs / mbuf clusters. Try looking into
> "vmstat -z" to see if there are enough mbuf clusters in various
> zones. Note well tha sendfile() normally blocks on disk, and it
> might simply mean that your disk sub
11 Янв 2017 г. 21:40 пользователь "Maxim Dounin"
написал:
Hello!
On Wed, Jan 11, 2017 at 08:54:31PM +0300, Руслан Закиров wrote:
> On Wed, Jan 11, 2017 at 6:44 PM, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Jan 11, 2017 at 06:07:01PM +0300, Руслан Закиров wrote:
> >
> > > On Mon, Jan 9,
Hello!
On Wed, Jan 11, 2017 at 08:54:31PM +0300, Руслан Закиров wrote:
> On Wed, Jan 11, 2017 at 6:44 PM, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Jan 11, 2017 at 06:07:01PM +0300, Руслан Закиров wrote:
> >
> > > On Mon, Jan 9, 2017 at 10:59 PM, Maxim Dounin
> > wrote:
> > >
> > > > Ty
On Wed, Jan 11, 2017 at 6:44 PM, Maxim Dounin wrote:
> Hello!
>
> On Wed, Jan 11, 2017 at 06:07:01PM +0300, Руслан Закиров wrote:
>
> > On Mon, Jan 9, 2017 at 10:59 PM, Maxim Dounin
> wrote:
> >
> > > Typical kern.sched.quantum is about 100ms, so several
> > > CPU-intensive tasks can delay proce
Hello!
On Wed, Jan 11, 2017 at 06:07:01PM +0300, Руслан Закиров wrote:
> On Mon, Jan 9, 2017 at 10:59 PM, Maxim Dounin wrote:
>
> > Typical kern.sched.quantum is about 100ms, so several
> > CPU-intensive tasks can delay processing of the events enough to
> > trigger a timeout if a context switc
On Mon, Jan 9, 2017 at 10:59 PM, Maxim Dounin wrote:
> Typical kern.sched.quantum is about 100ms, so several
> CPU-intensive tasks can delay processing of the events enough to
> trigger a timeout if a context switch happens at a bad time.
>
Here what I see in truss' output:
38.820523207 0.0
All hosts have characteristic stalls and blips but the scale of this issue can
vary 100x depending on is configuration. You can get some data about these
stalls using solar flare's sysjitter utility or Gil Tene's jhiccup.
Sent from my iPhone
On Jan 10, 2017, at 12:46 PM, Руслан Закиров wrote:
>
> > > The "upstream timeout ... while connecting to upstream" suggests
> > > that nginx wasn't able to see the connect event.
> > >
> > > [...]
> > >
> > > Some things to consider:
> > >
> > > - Make sure you are looking at tcpdump on the nginx host, and
> > > there are no firewalls on the host
Hello!
On Mon, Jan 09, 2017 at 09:56:54PM +0300, Руслан Закиров wrote:
> On Mon, Jan 9, 2017 at 6:14 PM, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Sun, Jan 08, 2017 at 05:04:47PM +0300, Руслан Закиров wrote:
> >
> > > Hello,
> > >
> > > nginx 1.10.2 [1] running on FreeBSD 10.3-RELEASE-p7
> >
On Mon, Jan 9, 2017 at 6:14 PM, Maxim Dounin wrote:
> Hello!
>
> On Sun, Jan 08, 2017 at 05:04:47PM +0300, Руслан Закиров wrote:
>
> > Hello,
> >
> > nginx 1.10.2 [1] running on FreeBSD 10.3-RELEASE-p7
> >
> > We have quite a lot of "upstream timed out" errors. For example:
> >
> > 2017/01/08 16:
Hello!
On Sun, Jan 08, 2017 at 05:04:47PM +0300, Руслан Закиров wrote:
> Hello,
>
> nginx 1.10.2 [1] running on FreeBSD 10.3-RELEASE-p7
>
> We have quite a lot of "upstream timed out" errors. For example:
>
> 2017/01/08 16:20:54 [error] 82154#0: *494223064 upstream timed out (60:
> Operation t
Hello,
nginx 1.10.2 [1] running on FreeBSD 10.3-RELEASE-p7
We have quite a lot of "upstream timed out" errors. For example:
2017/01/08 16:20:54 [error] 82154#0: *494223064 upstream timed out (60:
Operation timed out) while connecting to upstream, client: 192.168.1.43,
server: q0.sports.ru, reque
13 matches
Mail list logo
