Re: pgk_add segmentation fault
On Thursday 08 November 2007, Maslan wrote: > Hi, > > It seems that pkg_add tries to executes ldconfig which itself cause > the segmentation fault. > Yeah , I thought of that, and tested it. ldconfig works fine. # /sbin/ldconfig -m /usr/local/lib/mysql # > On Nov 8, 2007 7:44 AM, Aharon Schkolnik <[EMAIL PROTECTED]> wrote: > > Hi ! > > > > pkg_add is crashing with a segmentation fault: > > > > pkg_add -v mysql-client-5.1.22.tbz > > Requested space: 3809856 bytes, free space: 128323438592 bytes > > in /var/tmp/instmp.ND8UBU > > extract: Package name is mysql-client-5.1.22 > > extract: CWD to /usr/local > > extract: /usr/local/man/man1/mysql_config.1.gz > > extract: /usr/local/man/man1/mysql.1.gz > > extract: /usr/local/man/man1/mysqladmin.1.gz > > extract: /usr/local/man/man1/mysqlbinlog.1.gz > > extract: /usr/local/man/man1/mysqlcheck.1.gz > > extract: /usr/local/man/man1/mysqldump.1.gz > > extract: /usr/local/man/man1/mysqlimport.1.gz > > extract: /usr/local/man/man1/mysqlshow.1.gz > > extract: /usr/local/man/man8/mysqlmanager.8.gz > > . > > . > > . > > > > extract: /usr/local/lib/mysql/libmysqlclient_r.la > > extract: /usr/local/lib/mysql/libmysqlclient_r.so > > extract: /usr/local/lib/mysql/libmysqlclient_r.so.16 > > extract: /usr/local/share/aclocal/mysql.m4 > > extract: /usr/local/share/mysql/mysql_fix_privilege_tables.sql > > extract: execute '/sbin/ldconfig -m /usr/local/lib/mysql' > > extract: CWD to (null) > > Segmentation fault (core dumped) > > > > # uname -a > > FreeBSD CMXHost 5.30.0170 FreeBSD 5.30.0170 #0: Thu Apr 13 14:05:14 UTC > > 2006 i386 7.05.0014 > > > > > > Any ideas ? > > > > TIA > > -- > > The day is short, and the work is great,| Aharon Schkolnik > > and the laborers are lazy, and the reward | > > is great, and the Master of the house is| [EMAIL PROTECTED] > > impatient. - Ethics Of The Fathers Ch. 2| 054 8422076 > > ___ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "[EMAIL PROTECTED]" -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| [EMAIL PROTECTED] impatient. - Ethics Of The Fathers Ch. 2| 054 8422076 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pgk_add segmentation fault
On Friday 09 November 2007, Garrett Cooper wrote: > Aharon Schkolnik wrote: > > Hi ! > > > > pkg_add is crashing with a segmentation fault: > > > > pkg_add -v mysql-client-5.1.22.tbz > > Requested space: 3809856 bytes, free space: 128323438592 bytes > > in /var/tmp/instmp.ND8UBU > > extract: Package name is mysql-client-5.1.22 > > extract: CWD to /usr/local > > extract: /usr/local/man/man1/mysql_config.1.gz > > extract: /usr/local/man/man1/mysql.1.gz > > extract: /usr/local/man/man1/mysqladmin.1.gz > > extract: /usr/local/man/man1/mysqlbinlog.1.gz > > extract: /usr/local/man/man1/mysqlcheck.1.gz > > extract: /usr/local/man/man1/mysqldump.1.gz > > extract: /usr/local/man/man1/mysqlimport.1.gz > > extract: /usr/local/man/man1/mysqlshow.1.gz > > extract: /usr/local/man/man8/mysqlmanager.8.gz > > . > > . > > . > > > > extract: /usr/local/lib/mysql/libmysqlclient_r.la > > extract: /usr/local/lib/mysql/libmysqlclient_r.so > > extract: /usr/local/lib/mysql/libmysqlclient_r.so.16 > > extract: /usr/local/share/aclocal/mysql.m4 > > extract: /usr/local/share/mysql/mysql_fix_privilege_tables.sql > > extract: execute '/sbin/ldconfig -m /usr/local/lib/mysql' > > extract: CWD to (null) > > Segmentation fault (core dumped) > > > > # uname -a > > FreeBSD CMXHost 5.30.0170 FreeBSD 5.30.0170 #0: Thu Apr 13 14:05:14 UTC > > 2006 i386 7.05.0014 > > > > > > Any ideas ? > > > > TIA > > Where did you download those sources from? Could you get a backtrace > for me or point me to that package? I'm not positive where I got the package. I'll email it to you off-list. > Thanks, > -Garrett -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| [EMAIL PROTECTED] impatient. - Ethics Of The Fathers Ch. 2| 054 8422076 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD UFS/ZFS Snapshot Management Environment (20071111.1)
Based on various feedback I've now improved my FreeBSD Snapshot Management environment (people.freebsd.org/~rse/snapshot/). The new version 2007.1 is now available. In the past this was an abstraction layer for UFS snapshots only. Now it is an abstraction layer for both UFS and ZFS snapshot management and this way allows one to deal with snapshots during daily work independent whether one works on UFS or ZFS. To recap, this abstraction layer mainly provides three aspects: 1. common snapshot management frontend snapshot(8) for creating, destroying, listing, mounting, unmounting and temporarily visiting snapshots manually. 2. optional, automatic, periodic and flexible backup snapshot creation via periodic-snapshot(8) and a /etc/periodic.conf configuration, modeled after the NetApp Data ONTAP "snap sched" syntax. 3. optional, abstracted and easy access to backup snapshot data via amd(8) and the /snap hierarchy (not a big deal for ZFS but important for convenient access to UFS snapshots). The full functionality requires FreeBSD 7 or 8, of course. But FreeBSD 5 and 6 or also supported through the reduced UFS-only functionality. To get started: # download and installation $ cd /tmp $ fetch http://people.freebsd.org/~rse/dist/freebsd-snapshot-2007.1.tar.gz $ tar xzf freebsd-snapshot-2007.1.tar.gz $ cd freebsd-snapshot-2007.1 $ make install $ /etc/rc.d/amd start # OPTIONAL # just play with it by reading the details under # http://people.freebsd.org/~rse/snapshot/ $ [...] # deinstallation and cleanup $ cd /tmp/freebsd-snapshot-2007.1 $ make uninstall $ cd .. $ rm -rf freebsd-snapshot-2007.1* Happy snapshooting... ;-) -- [EMAIL PROTECTED]Ralf S. Engelschall FreeBSD.org/~rse [EMAIL PROTECTED] FreeBSD committer www.engelschall.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: amrd disk performance drop after running under high load
Hi. Kris Kennaway wrote: In the "good" case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the "good" and "bad" times, since it only provides counters and an average rate over the uptime of the system. Now I'm running 10-process lighttpd and the problem became no so big. I collected interrupt stats and it shows no relation beetween ionterrupts and slowdowns. Here is it: http://83.167.98.162/gprof/intr-graph/ Also I have similiar statistics on mutex profiling and it shows there's no problem in mutexes. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ I have no idea what else to check. I don't know what this graph is showing me :) When precisely is the system behaving poorly? Take a look at "Disk Load %" picture at http://83.167.98.162/gprof/intr-graph/ At ~ 17:00, 03:00-04:00, 13:00-14:00, 00:30-01:30, 11:00-13:00 it shows peaks of disk activity which really never happen. As I said in the beginning of the thread in this "peak" moments disk becomes slow and vmstat shows 100% disk load while performing < 10 tps. Other grafs at this page shows that there's no relation to interrupts rate of amr or em device. You advised me to check it. When I was using single-process lighttpd the problem was much harder as you can see at http://83.167.98.162/gprof/graph/ . At first picture on this page you can see disk load peaks at 18:00 and 15:00 which leaded to decreasing network output because disk was too slow. Back in this thread we suspected UMA mutexes. In order to check it I collected mutex profiling stats and draw graphs over time and they also didn't show anything interesting. All mutex graphs were smooth while disk load peaks. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ With best regards, Alexey Popov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some FreeBSD performance Issues
Hi All, Well, I've done some sleuthing and discovered some issues. First, the "dd" command produced approximately the same results everyone else was getting. So I rewrote a version of my test code in C using the stdlib "read" call and it had really great performance. Not understanding why C's code was so much faster, I dug into the source code and discovered that open/read/write/etc. use *buffered* I/O (which explains why "dd" performs so well). At this point I'm not sure why FreeBSD's API call is so slow (btw, it's not the system call that's responsible, if I make several additional API calls on each read, e.g., doing lseeks, this has only a marginal impact on performance). But it's pretty clear that if I expect reasonable performance in my own library I'm going to have to do the same thing that glib does and switch over to buffered I/O. Pain in the butt, but there's nothing else to do at this point. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: amrd disk performance drop after running under high load
On Nov 11, 2007 7:26 PM, Alexey Popov <[EMAIL PROTECTED]> wrote: > Hi. > > Kris Kennaway wrote: > >>> In the "good" case you are getting a much higher interrupt rate but > >>> with the data you provided I can't tell where from. You need to run > >>> vmstat -i at regular intervals (e.g. every 10 seconds for a minute) > >>> during the "good" and "bad" times, since it only provides counters > >>> and an average rate over the uptime of the system. > >> > >> Now I'm running 10-process lighttpd and the problem became no so big. > >> > >> I collected interrupt stats and it shows no relation beetween > >> ionterrupts and slowdowns. Here is it: > >> http://83.167.98.162/gprof/intr-graph/ > >> > >> Also I have similiar statistics on mutex profiling and it shows > >> there's no problem in mutexes. > >> http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ > >> > >> I have no idea what else to check. > > > I don't know what this graph is showing me :) When precisely is the > > system behaving poorly? > Take a look at "Disk Load %" picture at > http://83.167.98.162/gprof/intr-graph/ > > At ~ 17:00, 03:00-04:00, 13:00-14:00, 00:30-01:30, 11:00-13:00 it shows > peaks of disk activity which really never happen. As I said in the > beginning of the thread in this "peak" moments disk becomes slow and > vmstat shows 100% disk load while performing < 10 tps. Other grafs at > this page shows that there's no relation to interrupts rate of amr or em > device. You advised me to check it. > > When I was using single-process lighttpd the problem was much harder as > you can see at http://83.167.98.162/gprof/graph/ . At first picture on > this page you can see disk load peaks at 18:00 and 15:00 which leaded to > decreasing network output because disk was too slow. > > Back in this thread we suspected UMA mutexes. In order to check it I > collected mutex profiling stats and draw graphs over time and they also > didn't show anything interesting. All mutex graphs were smooth while > disk load peaks. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ > > With best regards, > Alexey Popov Hello, what is your RAID controller configuration (read ahead/cache/write policy)? I have seen weird/bogus numbers (~100% busy) reported by systat -v when read ahead was enabled on LSI/amr controllers. Regards, Panagiotis Christias ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
