Re: Local Sockets vs TCP
At 0:09 Uhr -0400 15.8.2001, Hans Zaunere wrote: Well I uncovered an interesting thing. If I use the regular old bin/mysql client to connect to the database (both on the same machine) and I run: ./mysql -uroot -p -h localhost Then run netstat -an , it shows that another /tmp/mysql.sock instance is connected, while the original /tmp/mysql.sock is ofcourse still listening. I've seen this too, the mysql command line client connects to the unix socket also if given 'localhost' as host. Don't know about DBD::mysql. And I was thinking, since a socket is a socket (just a file descriptor) whether local sockets or INET socks are getting used up, ssh still wouldn't work. Your problem probably was not running out of file descriptors, but running out of port numbers. Since every inet port (2^16 of them) after close takes some time until it can be used again, there may be no more free ports even if only few are actually in use concurrently. This is the reason why I've suggested persistent connections. christian. - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Local Sockets vs TCP
And I was thinking, since a socket is a socket (just a file descriptor) NO - a socket is not a file descriptor, something like a communication end/handshake point read more http://orkinos.cmpe.boun.edu.tr/netlab/courses/cmpe476/netprog/SocketsFAQ.txt Sure they are file descriptors, after all everything in UNIX is a file. They maybe special, but the kernel will still allocate a file descriptor for a socket. Section I.4 of the above link even says so. Hans [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Local Sockets vs TCP
These scripts should not be creating their own sockets. The should be connecting to the one socket that the mysql server creates. Hans Zaunere wrote: We have had a MySQL/Apache/Perl combo running fairly smoothly. However the other day MySQL seemingly went crazy, and brought the rest of the system down; no sockets were available, even to ssh into. After a few minutes, enough sockets were available to ssh into, however MySQL seemed to far gone, and had to be restarted. I have a feeling it is due to the scripts we are running (mod_perl via apache and regular perl, via local cronjobs) and the way they are written. All the scripts connect to MySQL via local UNIX domain sockets, thus creating a /tmp/mysql.sock for each invocation. Is this the best way to do it, or should TCP/IP sockets be used, by connecting to the full hostname, versus connecting to localhost, which seems to use local sockets. I know the local sockets are generally considered faster, however I have also heard that the Linux kernel does not handle a lot of local sockets well. Would a combination of local and IP sockets be used, or strictly IP, since strictly local sockets seems to bring the system to the edge. As much information, links, comparasions, benchmarks, data on the subject would be greatly appreciated. Don't hesitate to contact me for additional questions/info. Thank you, Hans Zaunere [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php attachment.txt Content-Type: text/plain -- Gerald L. Clark [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Local Sockets vs TCP
Ok. I didn't write these scripts, as they were in place when I arrived at this position, however from looking through them, it appears the actual connection to MySQL happens with something like: my $dbh = connect(DBI:mysql:database:localhost, user, password); The above is a perl line. So you are saying that the script should just open() /tmp/mysql.sock and read and write to it like any other file? And, if I am following, replacing the above localhost with the actual hostname of the machine would create a TCP/IP socket/connection to the server, which is the same as if I had to connect remotely? The above perl line is called from local scripts, executing from the perl interpreter via cron, and also in mod_perl scripts, running from Apache. These are essentially the same, correct? Thank you Hans Zaunere [EMAIL PROTECTED] Gerald Clark wrote: These scripts should not be creating their own sockets. The should be connecting to the one socket that the mysql server creates. Hans Zaunere wrote: We have had a MySQL/Apache/Perl combo running fairly smoothly. However the other day MySQL seemingly went crazy, and brought the rest of the system down; no sockets were available, even to ssh into. After a few minutes, enough sockets were available to ssh into, however MySQL seemed to far gone, and had to be restarted. I have a feeling it is due to the scripts we are running (mod_perl via apache and regular perl, via local cronjobs) and the way they are written. All the scripts connect to MySQL via local UNIX domain sockets, thus creating a /tmp/mysql.sock for each invocation. Is this the best way to do it, or should TCP/IP sockets be used, by connecting to the full hostname, versus connecting to localhost, which seems to use local sockets. I know the local sockets are generally considered faster, however I have also heard that the Linux kernel does not handle a lot of local sockets well. Would a combination of local and IP sockets be used, or strictly IP, since strictly local sockets seems to bring the system to the edge. As much information, links, comparasions, benchmarks, data on the subject would be greatly appreciated. Don't hesitate to contact me for additional questions/info. Thank you, Hans Zaunere [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php attachment.txt Content-Type: text/plain -- Gerald L. Clark [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Local Sockets vs TCP
Connect() does that for you. The mysql library handles the communication to the server. You just use the supplied functions. Are you sure it was sockets you were running out of? Hans Zaunere wrote: Ok. I didn't write these scripts, as they were in place when I arrived at this position, however from looking through them, it appears the actual connection to MySQL happens with something like: my $dbh = connect(DBI:mysql:database:localhost, user, password); The above is a perl line. So you are saying that the script should just open() /tmp/mysql.sock and read and write to it like any other file? And, if I am following, replacing the above localhost with the actual hostname of the machine would create a TCP/IP socket/connection to the server, which is the same as if I had to connect remotely? The above perl line is called from local scripts, executing from the perl interpreter via cron, and also in mod_perl scripts, running from Apache. These are essentially the same, correct? Thank you Hans Zaunere [EMAIL PROTECTED] Gerald Clark wrote: These scripts should not be creating their own sockets. The should be connecting to the one socket that the mysql server creates. Hans Zaunere wrote: We have had a MySQL/Apache/Perl combo running fairly smoothly. However the other day MySQL seemingly went crazy, and brought the rest of the system down; no sockets were available, even to ssh into. After a few minutes, enough sockets were available to ssh into, however MySQL seemed to far gone, and had to be restarted. I have a feeling it is due to the scripts we are running (mod_perl via apache and regular perl, via local cronjobs) and the way they are written. All the scripts connect to MySQL via local UNIX domain sockets, thus creating a /tmp/mysql.sock for each invocation. Is this the best way to do it, or should TCP/IP sockets be used, by connecting to the full hostname, versus connecting to localhost, which seems to use local sockets. I know the local sockets are generally considered faster, however I have also heard that the Linux kernel does not handle a lot of local sockets well. Would a combination of local and IP sockets be used, or strictly IP, since strictly local sockets seems to bring the system to the edge. As much information, links, comparasions, benchmarks, data on the subject would be greatly appreciated. Don't hesitate to contact me for additional questions/info. Thank you, Hans Zaunere [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php attachment.txt Content-Type: text/plain -- Gerald L. Clark [EMAIL PROTECTED] -- Gerald L. Clark [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Local Sockets vs TCP
Connect() does that for you. The mysql library handles the communication to the server. You just use the supplied functions. Are you sure it was sockets you were running out of? Well the supplied functions have been used. How could I confirm that the system was in fact running out of sockets or file descriptors. Do you know of any Linux kernel specific issues that hinder the use of a lot of local UNIX sockets. Any references/studies of the Linux kernel's problems with this sort of thing. Would it be better to just switch to TCP/IP sockets? Thank you, Hans Zaunere [EMAIL PROTECTED] Hans Zaunere wrote: Ok. I didn't write these scripts, as they were in place when I arrived at this position, however from looking through them, it appears the actual connection to MySQL happens with something like: my $dbh = connect(DBI:mysql:database:localhost, user, password); The above is a perl line. So you are saying that the script should just open() /tmp/mysql.sock and read and write to it like any other file? And, if I am following, replacing the above localhost with the actual hostname of the machine would create a TCP/IP socket/connection to the server, which is the same as if I had to connect remotely? The above perl line is called from local scripts, executing from the perl interpreter via cron, and also in mod_perl scripts, running from Apache. These are essentially the same, correct? Thank you Hans Zaunere [EMAIL PROTECTED] Gerald Clark wrote: These scripts should not be creating their own sockets. The should be connecting to the one socket that the mysql server creates. Hans Zaunere wrote: We have had a MySQL/Apache/Perl combo running fairly smoothly. However the other day MySQL seemingly went crazy, and brought the rest of the system down; no sockets were available, even to ssh into. After a few minutes, enough sockets were available to ssh into, however MySQL seemed to far gone, and had to be restarted. I have a feeling it is due to the scripts we are running (mod_perl via apache and regular perl, via local cronjobs) and the way they are written. All the scripts connect to MySQL via local UNIX domain sockets, thus creating a /tmp/mysql.sock for each invocation. Is this the best way to do it, or should TCP/IP sockets be used, by connecting to the full hostname, versus connecting to localhost, which seems to use local sockets. I know the local sockets are generally considered faster, however I have also heard that the Linux kernel does not handle a lot of local sockets well. Would a combination of local and IP sockets be used, or strictly IP, since strictly local sockets seems to bring the system to the edge. As much information, links, comparasions, benchmarks, data on the subject would be greatly appreciated. Don't hesitate to contact me for additional questions/info. Thank you, Hans Zaunere [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php attachment.txt Content-Type: text/plain -- Gerald L. Clark [EMAIL PROTECTED] -- Gerald L. Clark [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Local Sockets vs TCP
At 16:41 Uhr -0400 14.8.2001, Hans Zaunere wrote: sort of thing. Would it be better to just switch to TCP/IP sockets? my $dbh = connect(DBI:mysql:database:localhost, user, password); Well it seems like you ARE using INET TCP/IP sockets, since there is 'localhost' there (which goes over the loopback device). Not sure however if this syntax for specifying the host is correct, it's not mentioned this way in man DBD::mysql. And if you were running out of INET sockets so you couldn't connect with ssh anymore, it MUST have used INET sockets, doesn't it?... So try to strip this :localhost off. You could also use some persistent connection mechanism so that the script doesn't reconnect on each request. chj - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Local Sockets vs TCP
my $dbh = connect(DBI:mysql:database:localhost, user, password); Well I uncovered an interesting thing. If I use the regular old bin/mysql client to connect to the database (both on the same machine) and I run: ./mysql -uroot -p -h localhost Then run netstat -an , it shows that another /tmp/mysql.sock instance is connected, while the original /tmp/mysql.sock is ofcourse still listening. And I was thinking, since a socket is a socket (just a file descriptor) whether local sockets or INET socks are getting used up, ssh still wouldn't work. Does anyone have info on how good the Linux kernel is at handling local UNIX sockets vs. INET sockets? Thank you, Hans [EMAIL PROTECTED] Well it seems like you ARE using INET TCP/IP sockets, since there is 'localhost' there (which goes over the loopback device). Not sure however if this syntax for specifying the host is correct, it's not mentioned this way in man DBD::mysql. And if you were running out of INET sockets so you couldn't connect with ssh anymore, it MUST have used INET sockets, doesn't it?... So try to strip this :localhost off. You could also use some persistent connection mechanism so that the script doesn't reconnect on each request. chj --- -- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail mysql-unsubscribe- [EMAIL PROTECTED]Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
