From: Kyle S. <kyl...@sp...> - 2005-03-26 17:48:49
|
I'm sorry if this is covered already. As we know, running Fink can bog down a system. I'm aware that this isn't so much fink as it is the many process call-outs that happen while compiling. During this time frame, my system (G4 667 MHz Powerbook) becomes nearly useless. So this has led me to wondering: what is the quickest environment setup from which to execute fink commands? For example, 1) I have recently started to go to the Mac OS X login screen so I can ">console" in and run fink from there. I presume there's not the additional overhead that my full Aqua interface has, but I'm unaware if this also takes a hit as the console screen draw isn't exactly quick. I suppose I could do fink install finkapp > output.txt? 2) I am now just tinkering with a terminal app called GLTerm which boasts a quicker draw than Terminal.app. Given the verbosity of fink output, does this help? Or, would the redirect I'm thinking above moot that as well? 3) What else is there? Thanks in advance; Kyle |
From: Chris Z. <ch...@mi...> - 2005-03-26 19:51:12
|
On Mar 26, 2005, at 12:48 PM, Kyle Skrinak wrote: > I'm sorry if this is covered already. As we know, running Fink can bog > down a system. I'm aware that this isn't so much fink as it is the > many > process call-outs that happen while compiling. During this time frame, > my system (G4 667 MHz Powerbook) becomes nearly useless. So this > has led > me to wondering: what is the quickest environment setup from which to > execute fink commands? > > For example, 1) I have recently started to go to the Mac OS X login > screen so I can ">console" in and run fink from there. I presume > there's > not the additional overhead that my full Aqua interface has, but I'm > unaware if this also takes a hit as the console screen draw isn't > exactly quick. I suppose I could do fink install finkapp > output.txt? > 2) I am now just tinkering with a terminal app called GLTerm which > boasts a quicker draw than Terminal.app. Given the verbosity of fink > output, does this help? Or, would the redirect I'm thinking above moot > that as well? 3) What else is there? Outputting to a file may help, as may using a screen session. That way you could detach it from the terminal. The best thing to keep your machine useable, though, is to nice the process to the lowest priority. A `nice -n 20 fink install foo` works well. The machine will still bog down a little when there is heavy disk i/o, but that should still be better than it is now. -chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 ======================================================== ICBM Address: 39.795906N -75.056029W |
From: Robert T W. <rob...@au...> - 2005-03-26 20:03:10
|
Kyle, Since my home computer is shared with my significant other, we frequently need to use the computer while fink is compiling the sometimes hundreds of packages during the hours/days that it takes to do this. I have found that prefixing the commands with 'nice' (see 'man nice') is satisfactory for our general purposes. So one might issue 'nice fink install bundle-kde-ssl' and still keep the output (don't know if this can be done with 'backgrounding'--but it probably can)AND perform other operations like check e-mail without the otherwise-severe waiting that can be imposed. Now, if someone can tell me how to keep the build going after a power outage (like from a spring thunderstorm), I would be a VERY happy camper. HTH, Robert Kyle Skrinak wrote: > I'm sorry if this is covered already. As we know, running Fink can bog > down a system. I'm aware that this isn't so much fink as it is the many > process call-outs that happen while compiling. During this time frame, > my system (G4 667 MHz Powerbook) becomes nearly useless. So this has led > me to wondering: what is the quickest environment setup from which to > execute fink commands? > > For example, 1) I have recently started to go to the Mac OS X login > screen so I can ">console" in and run fink from there. I presume there's > not the additional overhead that my full Aqua interface has, but I'm > unaware if this also takes a hit as the console screen draw isn't > exactly quick. I suppose I could do fink install finkapp > output.txt? > 2) I am now just tinkering with a terminal app called GLTerm which > boasts a quicker draw than Terminal.app. Given the verbosity of fink > output, does this help? Or, would the redirect I'm thinking above moot > that as well? 3) What else is there? > > Thanks in advance; > Kyle |
From: Kyle S. <kyl...@sp...> - 2005-03-26 21:51:39
|
Robert T Wyatt <robert.wyatt <at> austin.utexas.edu> writes: [snip] > I have found that prefixing the commands with 'nice' (see 'man nice') is > satisfactory for our general purposes. [snip] Thanks for the suggestion to try nice-ing my fink priority down. I greatly appreciate your help! I've done this in the past, but I'm thinking an opposite tact. I'd like to shut down all non-fink supporting processes (such as windowing, menu bar updates, and be willing not to work while fink is finking) so that fink & co. gets as much CPU time as logistically possible (I know I can ratchet nice the other direction but I'm hope I'm being clear about the manner of tact.) This is why I've started going in the non-Aqua console direction. It does seem to me, however, that the console draws text more slowly, than Terminal/Aqua perhaps to fill the entire screen, or that some text rendering optimizing service isn't running in console? Thanks again; Kyle |
From: Robert T W. <rob...@au...> - 2005-03-27 00:32:44
|
Still, there is nice (note the second sentence, from 'man nice'): nice runs utility at an altered scheduling priority. If an increment is given, it is used; otherwise an increment of 10 is assumed. The super- user can run utilities with priorities higher than normal by using a neg- ative increment. The priority can be adjusted over a range of -20 (the highest) to 20 (the lowest). Use Chris' example and substitute -20 for 20. Kyle Skrinak wrote: > I'd like to shut down all non-fink supporting > processes (such as windowing, menu bar updates, and be willing not > to work while fink is finking) so that fink & co. gets as much CPU time > as logistically possible |
From: Robert T W. <rob...@au...> - 2005-03-27 15:21:01
|
... and also 'renice' for changing the niceness of running processes. Robert T Wyatt wrote: > Still, there is nice (note the second sentence, from 'man nice'): |
From: Aaron D. <ag...@co...> - 2005-03-27 01:44:01
|
On Mar 26, 2005, at 4:50 PM, Kyle Skrinak wrote: > Robert T Wyatt <robert.wyatt <at> austin.utexas.edu> writes: > > [snip] >> I have found that prefixing the commands with 'nice' (see 'man nice') >> is >> satisfactory for our general purposes. > [snip] > > Thanks for the suggestion to try nice-ing my fink priority down. I > greatly appreciate your help! I've done this in the past, but I'm > thinking an opposite tact. I'd like to shut down all non-fink > supporting > processes (such as windowing, menu bar updates, and be willing not > to work while fink is finking) so that fink & co. gets as much CPU time > as logistically possible (I know I can ratchet nice the other direction > but I'm hope I'm being clear about the manner of tact.) This is why > I've > started going in the non-Aqua console direction. It does seem to me, > however, that the console draws text more slowly, than Terminal/Aqua > perhaps to fill the entire screen, or that some text rendering > optimizing > service isn't running in console? Do you have any other computers? I would suggest logging out of Aqua, ssh'ing in from another computer, starting a GNU screen session, and running your fink commands inside that. Thanks to GNU screen, you can then detach and leave the compile jobs running, and there should be just about nothing but fink going on. -- __ __ / ) / ) /--/ __. .__ ______ / / __. , __o _ _ / (_(_/|_/ (_(_) / (_ (__/_(_/|_\/ <__</_/_)_ |
From: Chris Z. <ch...@mi...> - 2005-03-27 02:40:45
|
On Mar 26, 2005, at 8:43 PM, Aaron Davies wrote: > On Mar 26, 2005, at 4:50 PM, Kyle Skrinak wrote: > > >> Robert T Wyatt <robert.wyatt <at> austin.utexas.edu> writes: >> >> [snip] >> >>> I have found that prefixing the commands with 'nice' (see 'man >>> nice') is >>> satisfactory for our general purposes. >>> >> [snip] >> >> Thanks for the suggestion to try nice-ing my fink priority down. I >> greatly appreciate your help! I've done this in the past, but I'm >> thinking an opposite tact. I'd like to shut down all non-fink >> supporting >> processes (such as windowing, menu bar updates, and be willing not >> to work while fink is finking) so that fink & co. gets as much CPU >> time >> as logistically possible (I know I can ratchet nice the other >> direction >> but I'm hope I'm being clear about the manner of tact.) This is >> why I've >> started going in the non-Aqua console direction. It does seem to me, >> however, that the console draws text more slowly, than Terminal/Aqua >> perhaps to fill the entire screen, or that some text rendering >> optimizing >> service isn't running in console? >> > > Do you have any other computers? I would suggest logging out of > Aqua, ssh'ing in from another computer, starting a GNU screen > session, and running your fink commands inside that. Thanks to GNU > screen, you can then detach and leave the compile jobs running, and > there should be just about nothing but fink going on. Aqua is really not as much as a drain as you think. Use screen, no need to ssh in. nice -n 20 sets to lowest priority, so the box is still usable. nice -n -20 sets it to the highest priority. Note that this will make almost no difference in a mostly idle system anyway. distcc would help, if you have multiple systems. -chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 ======================================================== Remember: it's a "Microsoft virus", not an "email virus", a "Microsoft worm", not a "computer worm". |
From: Robert T W. <rob...@au...> - 2005-03-27 04:15:22
|
Understood everything but this (and thanks for the comments): Chris Zubrzycki wrote: > Use screen |
From: Kevin H. <kho...@ro...> - 2005-03-27 13:13:16
|
At 22:15 -0600 26/3/05, Robert T Wyatt wrote: >Understood everything but this (and thanks for the comments): > >Chris Zubrzycki wrote: >>Use screen > > I use screen quite a bit, as it puts the fink install stuff in the background, rather than having it continually update a Terminal window. I can also log in from my laptop to see how things are going with the install on the main computer. To start a new screen session: screen -R To save the output from the current session to a log file: Ctrl-a H To stop logging: Ctrl-a H To detach the current screen session (i.e. return to the original Terminal window, but have whatever was going on in screen continue, unseen): Ctrl-a d To reattach a screen session (from the same computer, or from another one that you are ssh'd in from): screen -R There are many more options - see man screen. |
From: Robert T W. <rob...@au...> - 2005-03-27 15:29:29
|
This is neat-hadn't heard of it before. The man page is huge and I'd like to get more familiar with setting screen to run fink compilations routing the log to a file (I understand this saves overhead on the display or buffer). There have been oblique references to detaching the session from Terminal so as to save the 7-8% cpu that it sucks up, does this mean that Terminal can be quit after spawning screen? Anyhow, do y'all know of a Web site or discussion list or a primer somewhere? (I did not find one in the man page, only the e-mail address of the developer.) I know that part of these questions have been answered below, but usage examples are golden to a fellow like myself. Thanks again! Kevin Horton wrote: > At 22:15 -0600 26/3/05, Robert T Wyatt wrote: > Understood everything but this (and thanks for the comments): >> >> Chris Zubrzycki wrote: >> Use screen > I use screen quite a bit, as it puts the fink install stuff in the > background, rather than having it continually update a Terminal window. > I can also log in from my laptop to see how things are going with the > install on the main computer. > > To start a new screen session: > screen -R > > To save the output from the current session to a log file: > Ctrl-a H > > To stop logging: > Ctrl-a H > > To detach the current screen session (i.e. return to the original > Terminal window, but have whatever was going on in screen continue, > unseen): > Ctrl-a d > > To reattach a screen session (from the same computer, or from another > one that you are ssh'd in from): > screen -R > > There are many more options - see man screen. |
From: Clemence M. <Cle...@sh...> - 2005-03-27 15:56:36
|
On Sun, Mar 27, 2005 at 09:28:59AM -0600, Robert T Wyatt wrote: > This is neat-hadn't heard of it before. The man page is huge and I'd > like to get more familiar with setting screen to run fink compilations > routing the log to a file (I understand this saves overhead on the > display or buffer). There have been oblique references to detaching the > session from Terminal so as to save the 7-8% cpu that it sucks up, does > this mean that Terminal can be quit after spawning screen? > I don't know anything about screen, but maybe this tip can help you: the nohup command allows you to run a process in the background, and prevent this process to be killed if its parent (i.e. the term it was launched from) terminates. So if you run : $ nohup some_command > output_file & this will run 'some_command', store its standard and error output in 'output_file', and it runs in the background, so you can do whatever you like with your term, like doing something else, closing it. You can also shut X11 down and logout, this will not prevent your command from running. Hope this helps, Clemence |
From: Robert T W. <rob...@au...> - 2005-03-27 16:28:11
|
Clemence Magnien wrote: > So if you run : > $ nohup some_command > output_file & > this will run 'some_command', store its standard and error output > in 'output_file', and it runs in the background, so you can > do whatever you like with your term, like doing something else, > closing it. You can also shut X11 down and logout, this will not > prevent your command from running. One of my issues is losing my ssh connection when my VPN client dis/connects; it sounds like nohup will survive that as well. |
From: Clemence M. <Cle...@sh...> - 2005-03-27 17:23:26
|
On Sun, Mar 27, 2005 at 10:27:58AM -0600, Robert T Wyatt wrote: > Clemence Magnien wrote: > >So if you run : > >$ nohup some_command > output_file & > >this will run 'some_command', store its standard and error output > >in 'output_file', and it runs in the background, so you can > >do whatever you like with your term, like doing something else, > >closing it. You can also shut X11 down and logout, this will not > >prevent your command from running. > > One of my issues is losing my ssh connection when my VPN client > dis/connects; it sounds like nohup will survive that as well. Yep, nohup will survive a logout from a ssh connection. As far as I know, the only way to kill a command launched with nohup is to: - kill it manually with the kill command - reboot the computer. I use it often, I find it great for launching a big program and not worry about it for days. Cheers, Clemence |
From: Aaron D. <ag...@co...> - 2005-03-27 17:38:48
|
On Mar 27, 2005, at 11:27 AM, Robert T Wyatt wrote: > Clemence Magnien wrote: >> So if you run : >> $ nohup some_command > output_file & >> this will run 'some_command', store its standard and error output in >> 'output_file', and it runs in the background, so you can >> do whatever you like with your term, like doing something else, >> closing it. You can also shut X11 down and logout, this will not >> prevent your command from running. > > One of my issues is losing my ssh connection when my VPN client > dis/connects; it sounds like nohup will survive that as well. nohup won't (AFAIK) allow you to "reattach" to a running process once you've logged out/been disconnected--it'll have lost it's connection to the terminal--but screen will. -- __ __ / ) / ) /--/ __. .__ ______ / / __. , __o _ _ / (_(_/|_/ (_(_) / (_ (__/_(_/|_\/ <__</_/_)_ |
From: Juan C. <cou...@ma...> - 2005-03-29 08:32:55
|
On Mar 27, 2005, at 9:57 AM, Clemence Magnien wrote: > On Sun, Mar 27, 2005 at 09:28:59AM -0600, Robert T Wyatt wrote: >> This is neat-hadn't heard of it before. The man page is huge and I'd >> like to get more familiar with setting screen to run fink compilations >> routing the log to a file (I understand this saves overhead on the >> display or buffer). There have been oblique references to detaching >> the >> session from Terminal so as to save the 7-8% cpu that it sucks up, >> does >> this mean that Terminal can be quit after spawning screen? >> > > I don't know anything about screen, but maybe this tip can help > you: the nohup command allows you to run a process in the background, > and prevent this process to be killed if its parent (i.e. the term it > was launched from) terminates. > > So if you run : > $ nohup some_command > output_file & Aren't you missing a 2>&1 in there? Cause in bash this will only save standard output but not standard error. > this will run 'some_command', store its standard and error output > in 'output_file', and it runs in the background, so you can > do whatever you like with your term, like doing something else, > closing it. You can also shut X11 down and logout, this will not > prevent your command from running. |
From: Clemence M. <Cle...@sh...> - 2005-03-29 09:27:22
|
On Tue, Mar 29, 2005 at 02:32:50AM -0600, Juan Courcoul wrote: > > On Mar 27, 2005, at 9:57 AM, Clemence Magnien wrote: > > > > >I don't know anything about screen, but maybe this tip can help > >you: the nohup command allows you to run a process in the background, > >and prevent this process to be killed if its parent (i.e. the term it > >was launched from) terminates. > > > >So if you run : > >$ nohup some_command > output_file & > > Aren't you missing a 2>&1 in there? Cause in bash this will only > save standard output but not standard error. Actually this is a little abusive indeed, but nohup redirects automatically the error output on the same file than the standard output (at least on the systems I have used nohup on, so I can tell this is the case for apple's nohup). Cheers, Clemence |
From: Matthew S. <ms...@ap...> - 2005-03-27 16:02:40
|
On Mar 27, 2005, at 10:28, Robert T Wyatt wrote: > Anyhow, do y'all know of a Web site or discussion list or a primer > somewhere? (I did not find one in the man page, only the e-mail > address of the developer.) Basic usage is to run 'screen' to get a new shell inside a screen session. Inside the screen session, hitting CTRL-a followed by some other key will do something to screen. CTRL-a ? will pull up screen's help. CTRL-a d will detach the screen session, removing it from your Terminal window. To reattach to a detached session so that you can see what's going on, invoke 'screen -r'. |
From: Chris Z. <ch...@mi...> - 2005-03-27 16:12:28
|
On Mar 27, 2005, at 11:02 AM, Matthew Sachs wrote: > On Mar 27, 2005, at 10:28, Robert T Wyatt wrote: > > >> Anyhow, do y'all know of a Web site or discussion list or a primer >> somewhere? (I did not find one in the man page, only the e-mail >> address of the developer.) >> > > Basic usage is to run 'screen' to get a new shell inside a screen > session. Inside the screen session, hitting CTRL-a followed by > some other key will do something to screen. CTRL-a ? will pull up > screen's help. CTRL-a d will detach the screen session, removing > it from your Terminal window. To reattach to a detached session so > that you can see what's going on, invoke 'screen -r'. screen -x is also a great tool, it lets you attach to a screen session more than once, meaning you can have the same session in more than one terminal window, even if they are on different machines. -chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 ======================================================== Everyone who comes in here wants three things: (1) They want it quick. (2) They want it good. (3) They want it cheap. I tell 'em to pick two and call me back. -- sign on the back wall of a small printing company |
From: Robert T W. <rob...@au...> - 2005-03-27 16:31:08
|
Matthew Sachs wrote: > On Mar 27, 2005, at 10:28, Robert T Wyatt wrote: >> Anyhow, do y'all know of a Web site or discussion list or a primer >> somewhere? (I did not find one in the man page, only the e-mail >> address of the developer.) > > Basic usage is to run 'screen' to get a new shell inside a screen > session. Inside the screen session, hitting CTRL-a followed by some > other key will do something to screen. CTRL-a ? will pull up screen's > help. CTRL-a d will detach the screen session, removing it from your > Terminal window. To reattach to a detached session so that you can see > what's going on, invoke 'screen -r'. So this will also survive a loss of the (parent) SSH connection. Sounds too good to be true! |
From: Matthew S. <ms...@ap...> - 2005-03-27 16:40:39
|
On Mar 27, 2005, at 11:30, Robert T Wyatt wrote: > <SNIP: screen> > > So this will also survive a loss of the (parent) SSH connection. > Sounds too good to be true! It will survive. (At first I was afraid, I was petrified / I thought that I could never live without a PTY...) |
From: Kevin H. <kho...@ro...> - 2005-03-27 17:23:01
|
At 9:28 -0600 27/3/05, Robert T Wyatt wrote: >This is neat-hadn't heard of it before. The man page is huge and I'd >like to get more familiar with setting screen to run fink >compilations routing the log to a file (I understand this saves >overhead on the display or buffer). There have been oblique >references to detaching the session from Terminal so as to save the >7-8% cpu that it sucks up, does this mean that Terminal can be quit >after spawning screen? Yes, you could quit Terminal after you detach the screen session (Ctrl-a d). But I don't think that the Terminal uses much CPU time after you detach the screen session, so I usually leave it running. Activity Monitor seems to show that Terminal uses less than 0.5% CPU just sitting there. Kevin Horton |
From: Chris M. <ch...@my...> - 2005-03-30 22:25:12
|
On 27 Mar 2005, at 4:28 pm, Robert T Wyatt wrote: > Anyhow, do y'all know of a Web site or discussion list or a primer > somewhere? (I did not find one in the man page, only the e-mail > address of the developer.) I learned about screen from this article: http://www.kuro5hin.org/story/2004/3/9/16838/14935 |
From: Dan S. <da...@to...> - 2005-03-26 21:51:44
|
On Sat, 26 Mar 2005 17:48:09 +0000 (UTC), Kyle Skrinak <kyl...@sp...> wrote: > ... As we know, running Fink can bog down a system. I'm aware that > this isn't so much fink as it is the many process call-outs that > happen while compiling. During this time frame, my system (G4 667 MHz > Powerbook) becomes nearly useless ... Oh you kids these days! ;-) "When I was a kid" (don't you hate it when us old people start a story that way? <g>), we used to run multiple users on 4MHz and 6MHz Z-80s. Okay, so we were all on 80x24 ASCII terminals, but we could all run our compilers (usually C and PL/I) and assemblers at the same time. These days, I have an aging (some might say ancient) 500MHz PowerMac G4, and while I do notice during compilations, my box is far from useless. I can surf the internet, check my email, read usenet, edit text files, develop non-CPU intensive software, and play various non-arcade games (including nethack, but that's another thread...), in Aqua and in X. I guess I do know better than to try to watch movies or expect anything phenomenal out of pov-ray. Are you running other programs while you're compiling? These days, it seems that everything wants a slice of your CPU even when you're not using it (e.g., to flush caches, to check for net-borne updates, to check to see if it's time to autosave, etc.), and lots of web pages have refreshes set up every few minutes to make sure that you get new ads. My compilations usually run in [iconized] xterms. As you already noted, Terminal.app isn't very quick to begin with, and it definitely comes to a crawl as the scrollback buffer grows. > ... have recently started to go to the Mac OS X login screen so I can > ">console" in and run fink from there ... I'm unaware if this also > takes a hit as the console screen draw isn't exactly quick ... My screen is 1920x1440 (I got spoiled by giant monitors at work), and the console interface is *extremely* slow. A small or iconized GUI terminal is much easier on the system. It is also possible that more RAM might help (RAM is faster than hard drives, especially in portable computers). I have 512MB, which now seems to be the minimum to run Mac OS X acceptably. (Don't get me started about the 1K (yes, *K*; or less) embedded environments in which I've had to make my software fit....) Regards, Dan -- Dan Sommers Atoms are not things. This sentence is false. --Werner Heisenberg <mailto:da...@to...> Intercourse the penguin. <http://www.tombstonezero.net/dan/> --Monty Python's Flying Circus |