-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
24.02.16 3:38, Heiler Bemerguy пишет:
>
>
> 23/02/2016 16:40, Yuri Voinov wrote:
>>
>> When you CPU's/cores waiting for HDD access, they got high-loag.
>>
>
> Are you sure it would show up as "User" load and not as "Wait" ?
Depending OS. Most li
23/02/2016 16:40, Yuri Voinov wrote:
When you CPU's/cores waiting for HDD access, they got high-loag.
Are you sure it would show up as "User" load and not as "Wait" ?
On linux "TOP" it shows something like:
%Cpu0 : 99,0 *us*, 1,0 sy, 0,0 ni, 0,0 id, 0,0 *wa*, 0,0 hi, 0,0
si, 0,0 st
Hey,
Some of the emails was probably off-list from some reason so responding
here.
Since you are having some issues with the current way that the proxy
works since it gets to 100% CPU and probably your clients\users
suffering from an issue I would suggest to try another approach to get
coup
On 02/23/2016 12:11 PM, Heiler Bemerguy wrote:
>
> Thanks Alex.
>
> We have a simple cache_dir config like this, with no "workers" defined:
> cache_dir rock /cache2 8 min-size=0 max-size=32767
> cache_dir aufs /cache 32 96 256 min-size=32768
FWIW, I do not know whether aufs and rock play
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The rule is simple.
If threads on processor(s) are in the queue to the disk - the bottleneck
is disk.
If the disks or network interfaces (IO threads) waits execution on
processor(s) - CPU(s) bottleneck.
PS. And, man, 1600 users is not a high load
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Agreed.
High-load big enough caches must utilize _an adequate_ hardware
configuration with enough capacity to meet you expectations.
And, of course, cache software configuration must fit this hardware, to
maximize approaches.
24.02.16 1:55, Amos
[ pPS please dont hijack other peoples threads ... this has nothing to
do with YouTube ]
On 24/02/2016 8:11 a.m., Heiler Bemerguy wrote:
>
> Thanks Alex.
>
> We have a simple cache_dir config like this, with no "workers" defined:
> cache_dir rock /cache2 8 min-size=0 max-size=32767
> cache_d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
A balanced server configuration, on common case, is:
At least 3 HDD spindels to 1 (one) CPU/core.
This is minimum. Also you need enough IO channels to this HDD's.
PC-like configuration is not playable here. 1600 clients already
required at a min
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
When you CPU's/cores waiting for HDD access, they got high-loag.
Just as a juggler trying to keep in the air 600 oranges. What do you
think would be a sweaty jogger? ;)
24.02.16 1:37, Yuri Voinov пишет:
>
>
>
> 24.02.16 1:11, Heiler Bemerguy пише
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
24.02.16 1:11, Heiler Bemerguy пишет:
>
> Thanks Alex.
>
> We have a simple cache_dir config like this, with no "workers" defined:
> cache_dir rock /cache2 8 min-size=0 max-size=32767
> cache_dir aufs /cache 32 96 256 min-size=32768
>
> A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
24.02.16 1:11, Heiler Bemerguy пишет:
This is obvious improvements.
If you have only one-two HDD controllers, you have bottleneck in IO. You
much cores waits HDD access alltogether.
First of all you need:
- - Either many HDD controlle
Thanks Alex.
We have a simple cache_dir config like this, with no "workers" defined:
cache_dir rock /cache2 8 min-size=0 max-size=32767
cache_dir aufs /cache 32 96 256 min-size=32768
And we are suffering from a 100% CPU use by a single squid thread. We
have lots of ram, cores and disk
On 02/23/2016 09:15 AM, Heiler Bemerguy wrote:
> I'm using Squid Cache: Version 3.5.14 and I'm wondering how big a file
> can be on a Rock Store nowardays ?
> Is it accepting the full "maximum_object_size" size?
Yes, for large-enough cache_dirs, it should.
AFAIK, there has been no optimization
Hi guys,
I'm using Squid Cache: Version 3.5.14 and I'm wondering how big a file
can be on a Rock Store nowardays ?
I saw 38 files stored on a cache_dir setup like this:
cache_dir rock /cache/rock4 10 min-size=104857601
Is it accepting the full "maximum_object_size" size? (which in my cas
14 matches
Mail list logo
