RE: [Asterisk-Users] 2 4-port T1 cards
1. Voicemail, and the voicemail itself will be stored on another box, NFS mounted, or I might use mysql. There will be a little bit of call routing via iax to a separate * box with a channel bank on it. 2. I don't disagree with you, they do throw in a lot, but redhat does have its advantages, IMHO. I've always been able to get things to work quickly with redhat, and there is that whole 24 hour support contract we have with them... 3. Mmm, ok. 4. Does the ati radeon 9000 have a frame buffer? That's the card I was going to use for all the * boxes. Thank you very much. -Joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Critchfield Sent: Tuesday, May 27, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] 2 4-port T1 cards On Tue, 2003-05-27 at 16:05, Joe Antkowiak wrote: Are there any known issues with putting 2 4-port T1 cards in a single box and having all ports and all channels in use at the same time? Planning on 4 of these boxes, dual AMD cpu MB from MSI, 512m, redhat 9, agp video, on board NICs, serial ata raid. Newbie 101 (Not deragatory) 1. What are you doing with these ports? If you are routing calls from one side of the cards to the other, then you should have no problems with a 1gig P3 or so. But if you are doing more than routing, it will depend on what that something is, and what kind of overhead it is going to impose. 2. RH blows chunks. (Personal opinion) RH is known to make kitchen sink installs when you don't need them, and would be better off without most of the install base. 3. Dual MB won't help much in pure telephony. In pure telephony, you are basically dealing with serial line IO. A T1 is little more than I long distance serial line. 8 T1s is just 11.7megs per second each way, or 23.4 megs in and out. Not too much for a good machine to do. Granted, if you are doing VoIP then you add another set of ins and outs with compression inthe middle of it too. This is where the second CPU comes in handy. 4. AGP Video. Make sure not to use the frame buffer, it has been reported that the frame buffer generates large amounts of interupts and will degrade the performance. Here is for discussion as it is parts I don't know real well. Will the serial ATA buy you any flexibilty or lowered CPU load while accessing the disk? Don't take this question as shooting down the SATA, just don't know if there is real benefit in it yet. Also what chipset is the onboard nics? -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] 2 4-port T1 cards
Cool, dual CPU it is =) I'll watch out for the frame buffers. Other than that, are there any other known issues with doing this? I will also be using dual-channel memory... Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Spencer Sent: Wednesday, May 28, 2003 12:38 AM To: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] 2 4-port T1 cards 3. Dual MB won't help much in pure telephony. In pure telephony, you are basically dealing with serial line IO. A T1 is little more than I long distance serial line. 8 T1s is just 11.7megs per second each way, or 23.4 megs in and out. Not too much for a good machine to do. Granted, if you are doing VoIP then you add another set of ins and outs with compression in the middle of it too. This is where the second CPU comes in handy. Actually, with Zaptel, and the T400P especially, dual CPU makes a *big* difference. The T400P and E400P are slave-only designs, so the CPU spends a lot of time just cramming I/O down the PCI bus. Having a second CPU free to do work will definitely help. 4. AGP Video. Make sure not to use the frame buffer, it has been reported that the frame buffer generates large amounts of interupts and will degrade the performance. Don't underestimate this effect or think that a fast CPU will get around it. frame buffer is a definite no-no because it disables interrupts during screen redraws which take an enormous amount of time. If your call quality drops while you're playing quake on your PBX, don't come crying to us ;-) Mark ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] 2 4-port T1 cards
On Wed, 2003-05-28 at 11:02, Joe Antkowiak wrote: 1. Voicemail, and the voicemail itself will be stored on another box, NFS mounted, or I might use mysql. There will be a little bit of call routing via iax to a separate * box with a channel bank on it. 2. I don't disagree with you, they do throw in a lot, but redhat does have its advantages, IMHO. I've always been able to get things to work quickly with redhat, and there is that whole 24 hour support contract we have with them... 3. Mmm, ok. 4. Does the ati radeon 9000 have a frame buffer? That's the card I was going to use for all the * boxes. Yes, it does., but just don't use that driver in the kernel and your okay. -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] 2 4-port T1 cards
On Wed, 2003-05-28 at 11:02, Joe Antkowiak wrote: 1. Voicemail, and the voicemail itself will be stored on another box, NFS mounted, or I might use mysql. There will be a little bit of call routing via iax to a separate * box with a channel bank on it. Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. Total file size of the database was under 200meg, and was fully cached so even though we had hardware raid 5 across 4 10K rpm ultra160 drives, it shouldn't have mattered for the selects. Also, NFS mounting of the voicemail for such a large install is probably not the best idea. Unless you really need it available to another machine, you _may_ want to rethink this idea. NFS can be a major speed hit on a machine, especially if the client is overworked. Also if you are planning on running most all the channels to voicemail, then do you think you are going to be able to have your NFS server keep high speed writing going so as not to slow you asterisk machine down with it's 96 channels running full tilt? 2. I don't disagree with you, they do throw in a lot, but redhat does have its advantages, IMHO. I've always been able to get things to work quickly with redhat, and there is that whole 24 hour support contract we have with them... 3. Mmm, ok. 4. Does the ati radeon 9000 have a frame buffer? That's the card I was going to use for all the * boxes. Thank you very much. -Joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Critchfield Sent: Tuesday, May 27, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] 2 4-port T1 cards On Tue, 2003-05-27 at 16:05, Joe Antkowiak wrote: Are there any known issues with putting 2 4-port T1 cards in a single box and having all ports and all channels in use at the same time? Planning on 4 of these boxes, dual AMD cpu MB from MSI, 512m, redhat 9, agp video, on board NICs, serial ata raid. Newbie 101(Not deragatory) 1. What are you doing with these ports? If you are routing calls from one side of the cards to the other, then you should have no problems with a 1gig P3 or so. But if you are doing more than routing, it will depend on what that something is, and what kind of overhead it is going to impose. 2. RH blows chunks. (Personal opinion) RH is known to make kitchen sink installs when you don't need them, and would be better off without most of the install base. 3. Dual MB won't help much in pure telephony. In pure telephony, you are basically dealing with serial line IO. A T1 is little more than I long distance serial line. 8 T1s is just 11.7megs per second each way, or 23.4 megs in and out. Not too much for a good machine to do. Granted, if you are doing VoIP then you add another set of ins and outs with compression in the middle of it too. This is where the second CPU comes in handy. 4. AGP Video. Make sure not to use the frame buffer, it has been reported that the frame buffer generates large amounts of interupts and will degrade the performance. Here is for discussion as it is parts I don't know real well. Will the serial ATA buy you any flexibilty or lowered CPU load while accessing the disk? Don't take this question as shooting down the SATA, just don't know if there is real benefit in it yet. Also what chipset is the onboard nics? -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] 2 4-port T1 cards
On Wed, 2003-05-28 at 13:30, Steven Critchfield wrote: Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. Total file size of the database was under 200meg, and was fully cached so even though we had hardware raid 5 across 4 10K rpm ultra160 drives, it shouldn't have mattered for the selects. I'd check what configuration problem you have with mysql then. Uptime: 48 days 1 hour 42 min 6 sec Threads: 15 Questions: 376005206 Slow queries: 22 Opens: 214 Flush tables: 1 Open tables: 64 Queries per second avg: 90.531 This is a mixture of inserts updates and selects as well. slashdot.org runs mysql at loads way over this, and it continues to run, although its very select heavy most likely. signature.asc Description: This is a digitally signed message part
RE: [Asterisk-Users] 2 4-port T1 cards
On Wed, 2003-05-28 at 14:30, Steven Critchfield wrote: Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. Total file size of the database was under 200meg, and was fully cached so even though we had hardware raid 5 across 4 10K rpm ultra160 drives, it shouldn't have mattered for the selects. What table type? The default MyISAM tables don't support row-level locking and thus are horrible if you do a lot of inserts or updates. InnoDB tables however are much, much better. Hell SlashDot runs on MySQL with InnoDB. :) -- Joshua M. Thompson [EMAIL PROTECTED] Planet Jurai ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] 2 4-port T1 cards
I've run tests with MySQL. It is very fast unless you have many processes that need to access it at once and then the weak point is it's locking method which let's only one process in at a time So you run into a wall as the size/complexity of your project grows past some point. But for a PBX all you are doing is using MySQL as a log file. It's a triveal application. Just one process doing a few inserts. This is where MySQL is at it's best. For the triveal case of one table and one process doing inserts I've done hundres per second but with a dozen processes and a doxen related tables we saw signs of the death spiral and even incorrect results and lock ups. The bigger, higher end DBMSes start out slower but scale better to more complex tasks and more concurent users. The fastest way to get between two points in a city using ground transport might be a motorcycle. But what if your job is to move 10,000 cases of beer between those two points. fastest is the wrong benchmark in that case. Even a slow and plodding horse drawn wagon would beat the bike at that job. It's kind of the same with databases. --- Ryan Butler [EMAIL PROTECTED] wrote: On Wed, 2003-05-28 at 13:30, Steven Critchfield wrote: Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. = Chris Albertson Home: 310-376-1029 [EMAIL PROTECTED] Cell: 310-990-7550 Office: 310-336-5189 [EMAIL PROTECTED] KG6OMK __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] 2 4-port T1 cards
On Wed, 2003-05-28 at 14:11, Ryan Butler wrote: On Wed, 2003-05-28 at 13:30, Steven Critchfield wrote: Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. Total file size of the database was under 200meg, and was fully cached so even though we had hardware raid 5 across 4 10K rpm ultra160 drives, it shouldn't have mattered for the selects. I'd check what configuration problem you have with mysql then. Uptime: 48 days 1 hour 42 min 6 sec Threads: 15 Questions: 376005206 Slow queries: 22 Opens: 214 Flush tables: 1 Open tables: 64 Queries per second avg: 90.531 This is a mixture of inserts updates and selects as well. This is partly why I qualified it with the statement with our application. I admit there was several things I inherited that are way sub optimal. Mysql didn't help matters when it went into it's death spiral though. Not all of it was the fault of Mysql, it just doesn't handle it gracefully. My biggest grip beyond table level locking was busy idling a process while the table was locked instead of giving up the processor so it could service the thread that had the table locked. I'd end up with 5+ processes queued up waiting for a table to be free using as much CPU as they could blocking on the table. slashdot.org runs mysql at loads way over this, and it continues to run, although its very select heavy most likely. Actually it is mostly cached. For the case of slashdot, 95% or more only read the front page, and the values of messages do not need to be accurate. Of the 5% that read deeper, very few actually post, and only the posts require anything more than selects. -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
On Wed, 2003-05-28 at 14:36, Ron Gage wrote: On Wednesday 28 May 2003 02:30 pm, Steven Critchfield wrote: On Wed, 2003-05-28 at 11:02, Joe Antkowiak wrote: 1. Voicemail, and the voicemail itself will be stored on another box, NFS mounted, or I might use mysql. There will be a little bit of call routing via iax to a separate * box with a channel bank on it. Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. Total file size of the database was under 200meg, and was fully cached so even though we had hardware raid 5 across 4 10K rpm ultra160 drives, it shouldn't have mattered for the selects. Um... I suppose that if MySQL can't handle more than 1.5 operations a second, someone should tell the folks at Slashdot and Yahoo that their choice of a DB engine isn't going to scale too well. See other post about why Slashdot isn't a good argument here. It applies equally well for Yahoo. They both are select heavy, and Mysql is able to parallelize these just fine. I also doubt Yahoo does it's updates to the production databases, they probably do it to a backend that then gets replicated to multiple less backends that do the real serving of data. For that matter, I suppose that GIS database I have here (the entire Tiger census data for the state of Michigan - 1.2 million type A records alone) isn't capable of handling more than 1.5 transactions a second. So, when I generate an AutoCAD script from the database records (generates a full-scale road map of the entire state of Michigan), it shouldn't be capable of running in under 10 minutes (at 1.5 transactions a second, it would take 13,333 minutes to run the script). Thats great for a single user. Now put 30 processes doing random updates and inserts while 5 users try and generate that map. I would strongly suggest that something is seriously messed up with your MySQL implementation if you are only capable of getting 1.5 transactions a second before the spiral of death. For comparison, I am running Mysql 4.0.12 on Slackware 9.0. AMD XP1800, 1 gig memory, single 73 gig SCSI-Wide drive, Adaptec 29160 controller. It can do a select distinct across the 1.2 million records in under 4 seconds. Again, 1 user on decent hardware, whoopeee. Try scaling that out and watch it die. -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
I'll save my typing fingers somewhat on this one - you are doing great arguing about all the crappiness of mysql and actually backing it up with real examples. It is nice to see that for a change in comparison to all the mysql lovers that love it just because but have no basis to compare it to something with heavy load. I, like you don't consider massive amounts of selects heavy at all. My example of heavy load where mysql could not even begin to handle the situation was a project with real time stock market data streamed in as bids and offers and trades happened, statistics computed from that in real time, database kept in sync live, and charts and graphs plotted in real time for users on the site. Now that situation had more than its share of inserts and updates, and a massive wad of historical data being kept just to add to the fun. Might I add for record that postgres did just fine. At 02:56 PM 5/28/2003 -0500, you wrote: On Wed, 2003-05-28 at 14:36, Ron Gage wrote: On Wednesday 28 May 2003 02:30 pm, Steven Critchfield wrote: On Wed, 2003-05-28 at 11:02, Joe Antkowiak wrote: 1. Voicemail, and the voicemail itself will be stored on another box, NFS mounted, or I might use mysql. There will be a little bit of call routing via iax to a separate * box with a channel bank on it. Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. Total file size of the database was under 200meg, and was fully cached so even though we had hardware raid 5 across 4 10K rpm ultra160 drives, it shouldn't have mattered for the selects. Um... I suppose that if MySQL can't handle more than 1.5 operations a second, someone should tell the folks at Slashdot and Yahoo that their choice of a DB engine isn't going to scale too well. See other post about why Slashdot isn't a good argument here. It applies equally well for Yahoo. They both are select heavy, and Mysql is able to parallelize these just fine. I also doubt Yahoo does it's updates to the production databases, they probably do it to a backend that then gets replicated to multiple less backends that do the real serving of data. For that matter, I suppose that GIS database I have here (the entire Tiger census data for the state of Michigan - 1.2 million type A records alone) isn't capable of handling more than 1.5 transactions a second. So, when I generate an AutoCAD script from the database records (generates a full-scale road map of the entire state of Michigan), it shouldn't be capable of running in under 10 minutes (at 1.5 transactions a second, it would take 13,333 minutes to run the script). Thats great for a single user. Now put 30 processes doing random updates and inserts while 5 users try and generate that map. I would strongly suggest that something is seriously messed up with your MySQL implementation if you are only capable of getting 1.5 transactions a second before the spiral of death. For comparison, I am running Mysql 4.0.12 on Slackware 9.0. AMD XP1800, 1 gig memory, single 73 gig SCSI-Wide drive, Adaptec 29160 controller. It can do a select distinct across the 1.2 million records in under 4 seconds. Again, 1 user on decent hardware, whoopeee. Try scaling that out and watch it die. -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
On Wed, 2003-05-28 at 15:09, Jon Pounder wrote: I'll save my typing fingers somewhat on this one - you are doing great arguing about all the crappiness of mysql and actually backing it up with real examples. It is nice to see that for a change in comparison to all the mysql lovers that love it just because but have no basis to compare it to something with heavy load. I, like you don't consider massive amounts of selects heavy at all. My example of heavy load where mysql could not even begin to handle the situation was a project with real time stock market data streamed in as bids and offers and trades happened, statistics computed from that in real time, database kept in sync live, and charts and graphs plotted in real time for users on the site. Now that situation had more than its share of inserts and updates, and a massive wad of historical data being kept just to add to the fun. Might I add for record that postgres did just fine. While I'm on the postgres bandwagon for now, I wouldn't want it in the middle of a phone system doing heavy call loads either. Postgres also has some downsides too. As I understand it, postgres doesn't understand prepared statements, or at least it doesn't via the perl DBI. Regardless I've seen our postgres database eat +2600 updates in under 2 seconds from a remote host on the same exact hardware that mysql choked on and not cause any degredation of access times for any other user. -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. Total file size of the database was under 200meg, and was fully cached so even though we had hardware raid 5 across 4 10K rpm ultra160 drives, it shouldn't have mattered for the selects. Wow! I thought it was just me. I actually went through the quite painfull migration process from mysql to postgresql in order to recover from mysql's death spiral. Ouch! Good advice. Mike Diehl ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
My example of heavy load where mysql could not even begin to handle the situation was a project with real time stock market data streamed in as bids and offers and trades happened, statistics computed from that in real time, database kept in sync live, and charts and graphs plotted in real time for users on the site. Now that situation had more than its share of inserts and updates, and a massive wad of historical data being kept just to add to the fun. ...and I can even top that. I had an Intrusion Detection System proof of concept which logged to a Postgresql database. This database received 10-15 Million inserts a day and I was required to keep 90 day's worth of data. Most of the elects were done in batch during slow times at night. Some of the queries were expected to run in near-real time. And might I also add that postgres did just fine... Might I add for record that postgres did just fine. Mike Diehl. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
was that mysql 3.23.x or 4.0.x ? michael *** REPLY SEPARATOR *** On 28.05.2003 at 16:18 [EMAIL PROTECTED] wrote: My example of heavy load where mysql could not even begin to handle the situation was a project with real time stock market data streamed in as bids and offers and trades happened, statistics computed from that in real time, database kept in sync live, and charts and graphs plotted in real time for users on the site. Now that situation had more than its share of inserts and updates, and a massive wad of historical data being kept just to add to the fun. ...and I can even top that. I had an Intrusion Detection System proof of concept which logged to a Postgresql database. This database received 10-15 Million inserts a day and I was required to keep 90 day's worth of data. Most of the elects were done in batch during slow times at night. Some of the queries were expected to run in near-real time. And might I also add that postgres did just fine... Might I add for record that postgres did just fine. Mike Diehl. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
Steven Critchfield wrote: Don't use Mysql. if you ever have had to deal with it in a production environment that works it over, you will know that as it reaches it's limits, it starts a death spiral that is very difficult to recover from. For our software on a dual P3 866 with a gig of ram, the limit was around 1.5 queries a second fairly mixed update, inserts, and selects. Total file size of the database was under 200meg, and was fully cached so even though we had hardware raid 5 across 4 10K rpm ultra160 drives, it shouldn't have mattered for the selects. You must have a major flaw in your database architecture. We very easily run 5-7 mixed queries a second on a nothing special Dell 1U PowerEdge server using MySQL-Max-3.23 and it doesn't even break a sweat. Jeremy McNamara ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
was that mysql 3.23.x or 4.0.x ? michael I did most of my mysql work some time ago with 3.x. I have, however, installed mysql 4.0.12 since I'm working on a CASE tool which needs to support both mysql and postgresql. I'll be the first to admit that mysql has probably improved (a lot?) since then. I was simply relating my experience with both mysql and postgresql. *** REPLY SEPARATOR *** On 28.05.2003 at 16:18 [EMAIL PROTECTED] wrote: My example of heavy load where mysql could not even begin to handle the situation was a project with real time stock market data streamed in as bids and offers and trades happened, statistics computed from that in real time, database kept in sync live, and charts and graphs plotted in real time for users on the site. Now that situation had more than its share of inserts and updates, and a massive wad of historical data being kept just to add to the fun. ...and I can even top that. I had an Intrusion Detection System proof of concept which logged to a Postgresql database. This database received 10-15 Million inserts a day and I was required to keep 90 day's worth of data. Most of the elects were done in batch during slow times at night. Some of the queries were expected to run in near-real time. And might I also add that postgres did just fine... Might I add for record that postgres did just fine. Mike Diehl. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] 2 4-port T1 cards
On 28 May 2003, Steven Critchfield waxed: 8's While I'm on the postgres bandwagon for now, I wouldn't want it in the middle of a phone system doing heavy call loads either. Postgres also has some downsides too. As I understand it, postgres doesn't understand prepared statements, or at least it doesn't via the perl DBI. Regardless I've seen our postgres database eat +2600 updates in under 2 seconds from a remote host on the same exact hardware that mysql choked on and not cause any degredation of access times for any other user. I've been using my own PostgreSQL CDR backend -- patches submitted -- without a hitch for months now, peak load is ~1000 calls/hr. The server, an Athlon XP1800+ w/256MB and a 40gig IDE HD, also serves up data for a calling card service with PGSQL, and hosts 3-6 clients for data entry. Up for 100+ days. I was going to put * on it, too ;) I'm running PostgreSQL 7.2, but 7.3 does provide for PREPARE'd queries on a per-connection basis, although they are dropped after the connection is closed and I'm not sure what fancy footwork Perl-DBI does. --Chris ps. While on this thread, I'm attaching my PG CDR patches again. -- Chris Maj cmaj_hat_freedomcorpse_hot_info 0xC0051F6A 5EB8 2035 F07B 3B09 5A31 7C09 196F 4126 C005 1F6A cdr_postgres.patches.tar.gz Description: Binary data
Re: [Asterisk-Users] 2 4-port T1 cards
3. Dual MB won't help much in pure telephony. In pure telephony, you are basically dealing with serial line IO. A T1 is little more than I long distance serial line. 8 T1s is just 11.7megs per second each way, or 23.4 megs in and out. Not too much for a good machine to do. Granted, if you are doingVoIP then you add another set of ins and outs with compression in the middle of it too. This is where the second CPU comes in handy. Actually, with Zaptel, and the T400P especially, dual CPU makes a *big* difference. The T400P and E400P are slave-only designs, so the CPU spends a lot of time just cramming I/O down the PCI bus. Having a second CPU free to do work will definitely help. 4. AGP Video. Make sure not to use the frame buffer, it has been reported thatthe frame buffer generates large amounts of interupts and will degrade the performance. Don't underestimate this effect or think that a fast CPU will get around it. frame buffer is a definite no-no because it disables interrupts during screen redraws which take an enormous amount of time. If your call quality drops while you're playing quake on your PBX, don't come crying to us ;-) Mark ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
