Re: [9fans] fossil+venti performance question
Hello! imho placing fossil, venti, isect, bloom and swap on single drive is bad idea. As written in in http://plan9.bell-labs.com/sys/doc/venti/venti.html - "The prototype Venti server is implemented for the Plan 9 operating system in about 10,000 lines of C. The server runs on a dedicated dual 550Mhz Pentium III processor system with 2 Gbyte of memory and is accessed over a 100Mbs Ethernet network. The data log is stored on a 500 Gbyte MaxTronic IDE Raid 5 Array and the index resides on a string of 8 Seagate Cheetah 18XL 9 Gbyte SCSI drives." God ide is to store isect on multiple SSD drives :) to speed up search. My small installation - 80Gb (PATA) 9fat, fossil, swap + 40Gb isect, bloom drive (PATA) + 1Tb SATA as arenas. No RAID. 2015-05-04 21:51 GMT+03:00 David du Colombier <0in...@gmail.com>: > I'm experiencing the same issue as well. > > When I launch vacfs on the same machine as Venti, > reading is very slow. When I launch vacfs on another > Plan 9 or Unix machine, reading is fast. > > I've just made some measurements when reading a file: > > Vacfs running on the same machine as Venti: 151 KB/s > Vacfs running on another machine: 5131 KB/s > > -- > David du Colombier > > -- С наилучшими пожеланиями Жилкин Сергей With best regards Zhilkin Sergey
Re: [9fans] fossil+venti performance question
Thanks Anthony. > I bet if you re-run the same test twice in a > row, you’re going to see dramatically improved > performance. I try to re-run ‘iostats md5sum /386/9pcf’. Read result is very fast. first read result is 152KB/s. second read result is 232MB/s. > Your write performance in that test isn’t really > relevant: they’re not hitting the file system at all. I think to write 1GB data to filesystem: iostats dd -if /dev/zero -of output -ibs 1024k -obs 1024k -count 1024 Write result of dd is 31MB/s. But this test may just write to fossil. It may not write to venti. > I’m not sure why you’d see a difference in a > fossil+venti setup of a different size, but the > partition size relationships, and the in-memory > cache size relationships, are what’s mostly important. My hardware has 2GB memory. Plan 9 configurations are almost default. (except /dev/sdC0/bloom) To increase memory size is difficult, because memory size is determined by public QEMU/KVM service plan. — kadota
Re: [9fans] fossil+venti performance question
On 4 May 2015 at 19:51, David du Colombier <0in...@gmail.com> wrote: > > I've just made some measurements when reading a file: > > Vacfs running on the same machine as Venti: 151 KB/s > Vacfs running on another machine: 5131 KB/s How many times do you time it on each machine?
Re: [9fans] fossil+venti performance question
Thanks Aram. > I have spent some time > debugging this, but unfortunately, I couldn't find the root cause, and > I just stopped using fossil. I tried to measure performance effect by replacement of component. 1) mbr or GRUB 2) pbs or pbslba 3) sdata or sdvirtio (sdvirtio is imported from 9legacy) 4) kernel configurations (9pcf, 9pccpuf, 9pcauth, etc) unfortunately, all of the above are no performance effect. — kadota
Re: [9fans] fossil+venti performance question
>> I've just made some measurements when reading a file: >> >> Vacfs running on the same machine as Venti: 151 KB/s >> Vacfs running on another machine: 5131 KB/s > > > How many times do you time it on each machine? Maybe ten times. The results are always the same ~5%. Also, I restarted vacfs between each try. It's easy to reproduce this issue with vacfs. I think anyone running Venti on Plan 9 can observe this problem. -- David du Colombier
Re: [9fans] fossil+venti performance question
I too see this, and feel, no proof, that things used to be better. I.e. the first time I read a file from venti it it very, very slow. subsequent reads from the ram cache are quick. I think venti used to be faster a few years ago. maybe another effect of this is the boot time seems slower than it used to be. sorry to be vague. -Steve > On 5 May 2015, at 15:47, KADOTA Kyohei wrote: > > Thanks Anthony. > >> I bet if you re-run the same test twice in a >> row, you’re going to see dramatically improved >> performance. > > I try to re-run ‘iostats md5sum /386/9pcf’. > Read result is very fast. > > first read result is 152KB/s. > second read result is 232MB/s. > >> Your write performance in that test isn’t really >> relevant: they’re not hitting the file system at all. > > I think to write 1GB data to filesystem: > >iostats dd -if /dev/zero -of output -ibs 1024k -obs 1024k -count 1024 > > Write result of dd is 31MB/s. > But this test may just write to fossil. It may not write to venti. > >> I’m not sure why you’d see a difference in a >> fossil+venti setup of a different size, but the >> partition size relationships, and the in-memory >> cache size relationships, are what’s mostly important. > > My hardware has 2GB memory. > Plan 9 configurations are almost default. (except /dev/sdC0/bloom) > To increase memory size is difficult, > because memory size is determined by public QEMU/KVM service plan. > > — > kadota
Re: [9fans] fossil+venti performance question
> I too see this, and feel, no proof, that things used to be better. I.e. the > first time I read a file from venti it it very, very slow. subsequent reads > from the ram cache are quick. > > I think venti used to be faster a few years ago. maybe another effect of this > is the boot time seems slower than it used to be. > > sorry to be vague. I'm pretty sure this issue started something like two years ago. It looks like a regression somewhere. -- David du Colombier
Re: [9fans] fossil+venti performance question
On 5 May 2015 at 16:38, David du Colombier <0in...@gmail.com> wrote: > > How many times do you time it on each machine? > > Maybe ten times. The results are always the same ~5%. > Also, I restarted vacfs between each try. It was the effect of the ram caches that prompted the question. My experience is similar to Steve's: it was faster, and now it's initially very very slow. I looked at changes from that version of venti to this, and I didn't see anything that would cause that. (The problem could be outside venti, but I looked at some possibly relevant kernel changes too.) Note that the raw drive speed on my venti machine is fine (no doubt it could be better, but it's fine). I convinced myself through experiments that the problem was with venti, not fossil. I used some debugging code in venti and had the impression that it took a surprisingly long time to handle each request: that the time was in venti. The effect was similar to that of a lost interrupt for a device driver. I used ratrace on it, but didn't spot an obvious culprit. I was tempted to rip out or disable the drive scheduling code in venti to see what happened, but not for the first time I ran out of time and had to get back to some other work. One thing I didn't know was that the results were different when fossil was on a different machine. I thought I'd tried that with vacfs myself, but apparently not or mine was as slow as when on the same machine.
Re: [9fans] fossil+venti performance question
semlocks? anyway, should not be too hard to figure out with /n/dump -- cinap
Re: [9fans] fossil+venti performance question
Yes, I'm pretty sure it's not related to Fossil, since it happens with vacfs as well. Also, Venti was pretty much unchanged during the last few years. I suspected it was related to the lock change on 2013-09-19. https://github.com/0intro/plan9/commit/c4d045a91e But I remember I tried to revert this change and the problem was still present. Maybe I should try again to be sure. -- David du Colombier
Re: [9fans] fossil+venti performance question
It's pretty interesting that at least three people all got exactly 150kB/s on vastly different machines, both real and virtual. Maybe the number comes from some tick frequency? -- Aram Hăvărneanu
[9fans] jumpy usb mouse on 9pi
Hello 9fans, I just got a used 3 button USB mouse (IBM-M-U35) which is giving me grief on a fresh 9pi image (board rev 0xe firmware rev: 1427481988). The mouse works fine plugged into Debian and OS X machines, but on 9pi, moving the mouse causes the cursor to jump erratically around the screen, almost exclusively in the vertical direction, along with rio registering button presses even though I'm not pressing any. Has anyone run into something similar? What can I do to try to address this? best, -- Paul Ivanov http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
Re: [9fans] jumpy usb mouse on 9pi
I have the same firmware, and an ibm m-u0013-o 3 button mouse, on a pi2 and it's working fine. I will try my pi1 tonight if I get time. Steve > On 6 May 2015, at 00:34, Paul Ivanov wrote: > > Hello 9fans, > > I just got a used 3 button USB mouse (IBM-M-U35) which is giving me grief on > a fresh 9pi image (board rev 0xe firmware rev: 1427481988). The mouse works > fine plugged into Debian and OS X machines, but on 9pi, moving the mouse > causes the cursor to jump erratically around the screen, almost exclusively > in the vertical direction, along with rio registering button presses even > though I'm not pressing any. > > Has anyone run into something similar? What can I do to try to address this? > > best, > -- > Paul Ivanov > http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
