On 08/06/16 19:07, Mark Kirkwood wrote:
changing this servers line to include the other proxy's memcache too
(e.g proxy 192.168.122.21 again):
$ cat /etc/swift/proxy-server.conf
...
[filter:cache]
use = egg:swift#memcache
memcache_servers = 192.168.122.21:11211,192.168.122.24:11211
I no
On 08/06/16 10:50, Mark Kirkwood wrote:
On 08/06/16 07:06, Pete Zaitcev wrote:
The proxies are load balanced behind Haproxy (which I'm guessing is
causing the 404 - see below)
HAproxy is often troublesome, but I don't expect it is at fault in
this instance. The logs that you quoted show that
On 08/06/16 07:06, Pete Zaitcev wrote:
On Fri, 3 Jun 2016 16:09:06 +1200
Mark Kirkwood wrote:
This is a Swift 2.7.0.1 system with 2 proxies and 3 storage nodes (each
the latter with 6 devices).
What is your replica count?
3 replicas for objects and containers
On Fri, 3 Jun 2016 16:09:06 +1200
Mark Kirkwood wrote:
> This is a Swift 2.7.0.1 system with 2 proxies and 3 storage nodes (each
> the latter with 6 devices).
What is your replica count?
> The proxies are load balanced behind Haproxy (which I'm guessing is
>
On 03/06/16 16:09, Mark Kirkwood wrote:
I'll dig up the Haproxy config and post. However any thoughts in the
meantime?
We have:
defaults
log global
maxconn 8000
option redispatch
retries 3
stats enable
timeout http-request 10s
timeout queue 1m
timeout connect 10s
Hi,
I did previously mention that I would start a new thread if I could
reproduce 'unexplained 404s'. Well, I can - however not for the exact
case I mentioned in the previous thread.
I have some python code using python-swiftclient that does:
for a number of containers:
create the