Hi,
I can confirm that this speeds up things.
Just noticed this thread and wondered if this could be as well the reason for
my “slow" serving of unversioned files. When using docker images to host
fossil, it uses fossil serve.
I just compiled the latest trunk on my Raspberry Pi and created a
The latest trunk check-in on Fossil
(http://www4.fossil-scm.org/info/05ec15cad53e8176) should do a much
better job of handling load from "fossil server". Please compile and
run it and let me know what happens.
The www4.fossil-scm.org server is running as follows:
/usr/local/bin/fossil
In message ,
Warren Young writes:
>On Dec 22, 2017, at 10:20 AM, Olivier R. wrote:
>>
>> Le 22/12/2017 à 16:10, Warren Young a écrit :
>>> 1. Your repo is public-facing. Is this a reasonable number of
>>> clients to be
Le 22/12/2017 à 21:34, Richard Hipp a écrit :
On 12/22/17, Olivier R. wrote:
I also run Fossil on a cheap VPS.
https://www.scaleway.com/virtual-cloud-servers/
(The starter version at €2.99/month)
I'm building up a new Fossil server on this VPS now - on an ARM64-2G
Le 22/12/2017 à 22:39, Richard Hipp a écrit :
On 12/22/17, Olivier R. wrote:
I also run Fossil on a cheap VPS.
Maybe you have used up your bandwidth quota and the ISP is throttling
your connection?
There is no bandwidth quota.
And when I kill the processes and
On 12/22/17, Olivier R. wrote:
>
> I also run Fossil on a cheap VPS.
Maybe you have used up your bandwidth quota and the ISP is throttling
your connection?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
On 12/22/17, Richard Hipp wrote:
> On 12/22/17, Olivier R. wrote:
>>
>> I also run Fossil on a cheap VPS.
>> https://www.scaleway.com/virtual-cloud-servers/
>> (The starter version at €2.99/month)
>>
>
> I'm building up a new Fossil server on this VPS now
On 12/22/17, Olivier R. wrote:
>
> I also run Fossil on a cheap VPS.
> https://www.scaleway.com/virtual-cloud-servers/
> (The starter version at €2.99/month)
>
I'm building up a new Fossil server on this VPS now - on an ARM64-2G
machine in Paris. It is slow-going.
Le 22/12/2017 à 18:41, Warren Young a écrit :
I’ve added the user to the “wireshark” group, but it doesn’t work.
You have to log out and back in before group changes will take
effect.
That’s what I did. But it didn’t work.
So I used `lsof -i:8080` again.
Here is the difference with the
Le 22/12/2017 à 19:57, Warren Young a écrit :
On Dec 22, 2017, at 9:03 AM, Warren Young
wrote:
Olivier, what about memory usage for the Fossil processes? “top”
can give you this.
I just checked my public server, and each of the 4 Fossil instances
is taking about 20 MB
On Dec 22, 2017, at 9:03 AM, Warren Young wrote:
>
> Olivier, what about memory usage for the Fossil processes? “top” can give
> you this.
I just checked my public server, and each of the 4 Fossil instances is taking
about 20 MB of VM, of which only about 800 kB is
On Dec 22, 2017, at 11:31 AM, Warren Young wrote:
>
> I posted a long HOWTO about it back in June of 2016:
>
> https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg23320.html
I just realized that that message is a reply to my post, not the post itself.
On Dec 22, 2017, at 10:53 AM, Tomek Kott wrote:
>
> FWIW I also run in server mode constantly because its easy. My users (there
> are 10, they probably hit the server in bursts of 10 times one one day of the
> week) occasionally notice slowdowns and ping me.
When I
FWIW I also run in server mode constantly because its easy. My users (there are
10, they probably hit the server in bursts of 10 times one one day of the week)
occasionally notice slowdowns and ping me. This is for an internal site only,
no public facing, so shouldn't be huge numbers of users.
On Dec 22, 2017, at 10:20 AM, Olivier R. wrote:
>
> Le 22/12/2017 à 16:10, Warren Young a écrit :
>
>> 1. Your repo is public-facing. Is this a reasonable number of
>> clients to be connected at any given time to this repo? It seems
>> high to me, given the transient
Le 22/12/2017 à 16:10, Warren Young a écrit :
1. Your repo is public-facing. Is this a reasonable number of
clients to be connected at any given time to this repo? It seems
high to me, given the transient nature of most Fossil connections.
Only two devs have the right to modify the online
Hello all:
In message
On Dec 22, 2017, at 8:56 AM, Richard Hipp wrote:
>
> (afaik) nobody uses "fossil server"
> for long-running websites.
I do. Mine stay running for months at a time, including public-facing ones.
> use the xinetd/inetd style of invoking Fossil
I can only see that helping if
On 12/22/17, Olivier R. wrote:
>
> I didn’t use Fossil 2.3 because the SQLite version bundled was in beta
> stage.
That is NOT a good reason to reject the use of Fossil 2.3.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users
On 12/22/17, Olivier R. wrote:
>
> I’ll have to kill all these processes soon and relaunch Fossil.
> I’ll do it when you think you have enough information about this
> problem. I’ll use Fossil 2.4 next time.
>
Maybe there is some kind of issue in the HTTP server
On Dec 22, 2017, at 8:24 AM, Olivier R. wrote:
>
> I’ll have to kill all these processes soon and relaunch Fossil.
> I’ll do it when you think you have enough information about this problem.
My request for connection rates doesn’t require that you keep Fossil running —
in
Le 22/12/2017 à 15:59, Richard Hipp a écrit :
On 12/22/17, Olivier R. wrote:
There is now more than 24 subprocesses of Fossil running, and it’s
getting really slow.
Are you saying that these 24 Fossils are spinning - using CPU cycles -
not just hung waiting on I/O?
On Dec 22, 2017, at 8:10 AM, Warren Young wrote:
>
> $ sudo tshark -b duration:1 port 8080 and tcp.flags.syn==1 | wc -l
Sorry, that’s bogus. Try this instead:
$ sudo tshark -i enp3s0 -w x.pcap -b duration:5 -a files:1 \
port 8080 and "tcp[tcpflags] & tcp-syn !=
On Dec 22, 2017, at 7:46 AM, Olivier R. wrote:
>
> Le 19/12/2017 à 21:49, Warren Young a écrit :
>
>> If it’s a sign of a bug, then it means something very bad has
>> happened, like the network stack has lost track of its client
>> somehow. To see that, you’d need to do a
On 12/22/17, Olivier R. wrote:
>
> There is now more than 24 subprocesses of Fossil running, and it’s
> getting really slow.
Are you saying that these 24 Fossils are spinning - using CPU cycles -
not just hung waiting on I/O?
--
D. Richard Hipp
d...@sqlite.org
Le 19/12/2017 à 21:49, Warren Young a écrit :
If it’s a sign of a bug, then it means something very bad has
happened, like the network stack has lost track of its client
somehow. To see that, you’d need to do a network capture on that
fossil instance’s network sockets. Use netstat -nap or
On Dec 19, 2017, at 1:49 PM, Warren Young wrote:
>
> If it’s a sign of a bug, then it means something very bad has happened, like
> the network stack has lost track of its client somehow. To see that, you’d
> need to do a network capture on that fossil instance’s network
On Dec 19, 2017, at 5:20 AM, Olivier R. wrote:
>
> #0 0x7fd8ff85e873 in __select_nocancel () at
> ../sysdeps/unix/syscall-template.S:81
> #0 0x7fd8ff85e873 in __select_nocancel () at
> ../sysdeps/unix/syscall-template.S:81
> #0 0x7fd8ff858ba0 in
Le 19/12/2017 à 02:00, Warren Young a écrit :
On Dec 18, 2017, at 6:52 AM, Olivier R. wrote:
When gdb was active, Fossil didn’t answer when asking for a
webpage. It seemed blocked.
That’s exactly what happens. If you want the process to run while
GDB remains attached,
On Dec 18, 2017, at 7:04 PM, bch wrote:
>
> Does contemporary Linux not randomize its PIDs?
It may be an option, but it isn’t happening on a near-stock CentOS 7 box I have
near at hand here:
$ ls > /dev/null & echo $!
Run that repeatedly on a quiet system, and
On Mon, Nov 6, 2017 at 9:19 AM Warren Young wrote:
> On Nov 3, 2017, at 12:08 PM, Richard Hipp wrote:
> >
> > On 11/3/17, Olivier R. wrote:
> >>
> >>
> >> Sorry. My knowledge of the C toolchain is null.
> >
> > The next step will be to
On Dec 18, 2017, at 6:52 AM, Olivier R. wrote:
>
> When gdb was active, Fossil didn’t answer when asking for a webpage. It
> seemed blocked.
That’s exactly what happens. If you want the process to run while GDB remains
attached, say “cont” after attaching.
> Here is
OK. It happened again while I was away for few days.
The main process has created 10 subprocesses. Fossil was very slow.
I used gdb on the main process.
When gdb was active, Fossil didn’t answer when asking for a webpage. It
seemed blocked. And Fossil was responsive again few seconds after I
Le 06/11/2017 à 18:19, Warren Young a écrit :
The remaining PIDs are all certainly a single parent with multiple
children. You’d have to run top in “tree” mode or show the PPID
column to find out which one is the parent. You can tell without
doing that by the fact that all of the VIRT column
On Nov 3, 2017, at 12:08 PM, Richard Hipp wrote:
>
> On 11/3/17, Olivier R. wrote:
>>
>>
>> Sorry. My knowledge of the C toolchain is null.
>
> The next step will be to figure out
> how to attach the debugger to a hung process.
Problem #1 could be
On 11/3/17, Olivier R. wrote:
> Le 03/11/2017 à 10:22, Richard Hipp a écrit :
>> On 11/3/17, Olivier R. wrote:
>>>
>>> And today, Fossil was already very slow and I discovered that there were
>>> more than ten processes of Fossil running.
>>
>> Can you
Le 03/11/2017 à 10:22, Richard Hipp a écrit :
On 11/3/17, Olivier R. wrote:
And today, Fossil was already very slow and I discovered that there were
more than ten processes of Fossil running.
Can you compile with symbols enabled ("-g") and then attach to one of
the
On 11/3/17, Olivier R. wrote:
>
> And today, Fossil was already very slow and I discovered that there were
> more than ten processes of Fossil running.
Can you compile with symbols enabled ("-g") and then attach to one of
the hung processes using a debugger to see what it
Hi everyone,
There is a fossil repo I run on a server since several months. And I
noticed several times a behavior I don’t understand at all.
After few months of running sweetly, I noticed that the fossil server
was getting slower and slower. The repo is about 120 Mb only.
Then I discovered
39 matches
Mail list logo