| 00:21.48 | Juggie | jsmith-away, :( |
| 00:59.34 | *** join/#asterisk-doc fakhir (n=Fakhir@unaffiliated/fakhir) |
| 01:43.35 | *** join/#asterisk-doc codefreeze (n=steve_mu@216.166.159.235) |
| 01:43.35 | *** join/#asterisk-doc snuff-away (i=snuff@220-253-41-30.VIC.netspace.net.au) [NETSPLIT VICTIM] |
| 01:43.35 | *** join/#asterisk-doc snuff-work (n=na@61.29.30.137) [NETSPLIT VICTIM] |
| 02:52.53 | Juggie | i had to do a reinstall but it looks like fedora is playing nice this time |
| 02:53.15 | Juggie | i probally broke it trying to install the ati closed source driver |
| 02:53.24 | Juggie | comparatively, nvidia's driver install was a dream |
| 02:54.07 | Juggie | ran their installer, it told me my video card was old and i needed an older driver version and told em the exact version to get, so i got it, ran again, it did everything, compiled a kernel module for me and tada works great |
| 03:18.09 | snuff-work | mm i had issue that is 'known' with 2.6.23 :) |
| 03:18.27 | snuff-work | and nvidia closed source driver |
| 03:18.57 | snuff-work | just few changes required to 'k_mem_somethin..' |
| 06:52.42 | *** join/#asterisk-doc file (n=file@neutrino-114-86.joshua-colp.com) |
| 11:42.31 | *** join/#asterisk-doc codefreeze (n=steve_mu@216.166.159.235) |
| 13:08.34 | *** join/#asterisk-doc Alric (n=nbowyer@masq.hyperusa.com) |
| 13:24.06 | ctooley | morning Alric |
| 13:24.16 | ctooley | go away file. |
| 13:25.06 | file | I am a constant of this channel, I can't go away |
| 13:25.29 | Alric | void const file; |
| 13:25.41 | file | pfft |
| 13:25.43 | Alric | Err, can you even do that? |
| 13:26.49 | Alric | jsmith: Ping? |
| 13:27.18 | jsmith | Alric: Pong |
| 13:27.27 | Alric | jsmith: Ever messed with database clustering? |
| 13:27.53 | jsmith | Alric: Yup |
| 13:28.16 | Alric | We're having database bottlenecks /somewhere/. Looking at clustering. |
| 13:29.07 | jsmith | Alric: Clustering probably isn't the answer. You should first figure out *why* you're having bottlenecks. |
| 13:29.33 | jsmith | Alric: Is it table problems? Lack of indices? Slow-running queries? Unoptimized queries? |
| 13:29.41 | jsmith | Alric: Unvacuumed tables? |
| 13:29.45 | Alric | Probably a combination of all of the above. |
| 13:30.13 | jsmith | Running MySQL over NFS probably isn't a good thing. |
| 13:30.25 | Alric | We're putting pretty much everything on a centralized SQL server, which mounts an NFS drive to store everything on. |
| 13:30.42 | jsmith | Why? |
| 13:31.16 | Alric | Why which part? |
| 13:31.22 | jsmith | That's like saying "We're putting all our money in one cash register, but instead of putting the money in the drawer, we're going to walk it to the back office every transaction" |
| 13:31.39 | jsmith | Why have the one SQL server store the data over NFS? |
| 13:31.46 | Alric | Brass likes NFS drives |
| 13:33.11 | jsmith | Brass ain't got no brains either... |
| 13:33.25 | jsmith | ... no wonder you're having database issues |
| 13:33.29 | Alric | :D |
| 13:33.42 | Alric | Indicies are also a problem, but I'm not sure how much of that can be optimized. |
| 13:34.02 | jsmith | You're using MySQL, right? |
| 13:34.14 | Alric | Some of these databases are the way they are because of how rather unchangeable elements want to do things (CDR outputs from switches, etc) |
| 13:34.16 | Alric | Yeah. |
| 13:34.23 | jsmith | That means you only get one index per query, so make sure you have a *good* set of indices for each of your most common queries |
| 13:34.45 | Alric | pgsql would be better in that regard? |
| 13:34.52 | jsmith | Yes. |
| 13:35.09 | Alric | How different is database design and syntax in pgsql |
| 13:35.09 | Alric | ? |
| 13:35.13 | jsmith | PgSQL (or *very* recent versions of MySQL I think) can use multiple indices per query. |
| 13:35.26 | jsmith | Alric: Not much... (better I'd say, but some will argue against me) |
| 13:35.29 | Alric | We're running MySQL 5. |
| 13:35.35 | Alric | 5.02 or so. |
| 13:35.51 | file | as having used both MySQL and Postgresql, I like Postgresql better myself |
| 13:36.11 | jsmith | I don't remember when they added the multiple index support... and it may only be for certain table types |
| 13:36.26 | jsmith | Well, I used to manage one of the 5 largest MySQL installations in the world... that's reason enough to use PostgreSQL right there |
| 13:36.38 | jsmith | I learned more about the awful parts of MySQL than I care to share |
| 13:36.40 | file | jsmith: :D |
| 13:36.42 | Alric | This isn't really a matter of can we techie types adapt to a new database type. |
| 13:37.27 | Alric | We 1) have tons of unabstracted code that relies on database calls. 2) Have management that loves MySQL. |
| 13:37.51 | Alric | I guess I need to stop using SELECT * FROM ... though :D |
| 13:38.04 | jsmith | Alric: Well, then do the best you can with what you've got. Having MySQL read/write across NFS is *far* from ideal. |
| 13:38.38 | Alric | I suspect that is where the problem is. We're in the process of copying one of the databases to a local drive to run more tests on. |
| 13:39.14 | jsmith | Have you looked for long-running queries? |
| 13:39.21 | jsmith | Are you running into problems with table locks? |
| 13:40.05 | Alric | I don't even know how to test for table lock problems. |
| 13:40.13 | Alric | And we do have long-running queries. |
| 13:41.18 | Alric | Lots of billing-esque and CDR-type stuff happens on a daily basis. Loads down the DB server in some fashion (but not CPU / memory) so the user-type queries don't happen timely. |
| 13:48.11 | ctooley | There's nothing wrong with MySQL |
| 13:48.29 | ctooley | What table types are you using? MyISAM or Innodb? |
| 13:48.48 | Alric | MyISAM |
| 13:49.00 | ctooley | Are you using replication of any kind? |
| 13:49.04 | Alric | No |
| 13:50.00 | ctooley | Well, to start with, if you're really worried about having your data on the NFS server backup purposes, install MySQL on the NFS server and replicate to it from SQL server. Then it doesn't matter that the database doesn't live there. |
| 13:50.02 | jsmith | ctooley: Sure there is... only being able to have one index per query, not having true referential integrity without going to InnoDB tables.. |
| 13:50.20 | jsmith | ctooley: Like I said earlier... I've got *way* too much MySQL experience to like it anymore |
| 13:50.37 | ctooley | jsmith, MySQL has perfectly good support for multi-index queries. |
| 13:50.40 | jsmith | ctooley: Oh, and did I mention having MyISAM tables that took 12 days to run myisamchk on |
| 13:50.48 | jsmith | ctooley: Finally, with version 5.something |
| 13:51.24 | jsmith | ctooley: With versions 3 and 4 and the early 5.x versions, you could *have* multiple indices, they just wouldn't get used. |
| 13:51.38 | jsmith | ctooley: MySQL would only *use* one index per query |
| 13:51.44 | jsmith | (and would often choose a poor one) |
| 13:51.53 | ctooley | jsmith, after spending a long week of no sleep trying to restore a pgsql database, I still lost data because of the piss poor way it logged transactions in earlier versions. |
| 13:52.12 | jsmith | Hey, at least you get transactions! |
| 13:52.30 | file | DRINK! |
| 13:52.32 | ctooley | innodb has supported innodb for a long time. |
| 13:52.52 | jsmith | ctooley: Yeah, and InnoDB belongs to Oracle now |
| 13:52.55 | Alric | innodb has supported innodb? |
| 13:53.10 | ctooley | innodb has supported transactions. sorry |
| 13:53.14 | ctooley | jsmith, so? |
| 13:53.16 | jsmith | Let's make this a good flamewar, shall we? |
| 13:53.49 | jsmith | ctooley: Yes, it's supported transactions, but not as well as PostgreSQL... besides, transactional queries in PostgreSQL are faster than MySQL if you're using InnoDB tables |
| 13:54.08 | jsmith | ctooley: Believe me, we tried as hard as we could to move from MyISAM to InnoDB tables |
| 13:54.08 | ctooley | Asterisk "belongs" to Digium, if Mark was taken over by aliens and they became evil, Asterisk would still live on, hence the purpose of Open Source. |
| 13:54.26 | jsmith | ctooley: At least that's one thing we can agree on |
| 13:54.39 | ctooley | Same thing with innodb |
| 13:55.19 | ctooley | We're moving everything to MySQL and getting great performance out of our innodb tables. |
| 13:55.59 | ctooley | depending on the day of the week we'll write 15-20 million CDRs a day. Each of which are over 2K |
| 13:56.07 | *** join/#asterisk-doc blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:56.07 | *** mode/#asterisk-doc [+o blitzrage] by ChanServ |
| 13:56.18 | jsmith | blitzrage! |
| 13:56.22 | ctooley | The rating process runs against the same tables, on the same server. |
| 13:56.24 | blitzrage | jsmith! |
| 13:56.33 | ctooley | reporting runs against a different replica |
| 13:57.03 | jsmith | ctooley: With our databases, performance looked like this: (with MyISAM tables being rated 1.0 in terms of speed) |
| 13:57.07 | jsmith | MyISAM: 1.0 |
| 13:57.09 | ctooley | The only thing we really see slowdowns in is the replica can get behind because everything is done serially. |
| 13:57.19 | jsmith | PostgreSQL 7.4: 1.35 |
| 13:57.31 | jsmith | PostgreSQL 8.1: 1.18 |
| 13:57.49 | jsmith | MyISAM under MySQL 5: 0.97 |
| 13:57.58 | jsmith | InnoDB under MySQL 5: 1.4 |
| 13:58.16 | jsmith | That's the mean time over 10,000 queries |
| 13:58.18 | ctooley | lower being better? |
| 13:58.22 | jsmith | Lower being better. |
| 13:58.43 | ctooley | I guess it depends on your queries. |
| 13:58.53 | jsmith | InnoDB tables added 40% overhead, which we couldn't deal with (considering we were handing around 200 *Billion* queries per day) |
| 13:58.56 | ctooley | We're doing 5,000 queries/second |
| 13:59.07 | ctooley | write queries that is. |
| 13:59.18 | ctooley | Our read performance was blinding. |
| 14:00.04 | jsmith | We were doing 2.3 million queries per second |
| 14:00.10 | jsmith | And about 80% of those were writes |
| 14:00.37 | jsmith | (Most of our reads came from Trie files in memory, and not directly against MySQL) |
| 14:00.45 | ctooley | should point out that we're doing that performance on relatively puny hardware with very large writes. |
| 14:01.22 | ctooley | Our only bottleneck we run into on our primary server is disk i/o |
| 14:01.47 | jsmith | Yup... same problem we ran into... even with 15,000 RPM SCSI disks, it's still a bottleneck |
| 14:01.52 | ctooley | We have had the slow query log turned on and haven't found one in well over a month. When we do, we optimize for it. |
| 14:02.08 | ctooley | And that's not going to be different between the two. |
| 14:02.15 | file | so much database talk.... |
| 14:02.56 | Alric | Slow query log? |
| 14:03.02 | ctooley | jsmith, yeah I will agree with you there. |
| 14:03.33 | ctooley | Alric, if you don't know what the slow query log is, you definitely need to do some reading. (I mean no offense by that.) |
| 14:03.36 | jsmith | Alric: You don't know about the slow query log? |
| 14:03.45 | jsmith | Alric: That's where I'd begin if I were you |
| 14:04.08 | ctooley | Alric, there's a log file that MySQL puts long running queries into so they can be optimized. Use EXPLAIN to learn how to make them perform better. |
| 14:04.17 | Alric | Database is not my thing, I'm just in here because no one else is a real database person either :D |
| 14:04.51 | ctooley | yeah, go read the MySQL docs about optimizing performance |
| 14:04.58 | ctooley | There's a LOT you can do to improve things. |
| 14:05.19 | jsmith | Alric: O'Reilly has a great book (slightly out of date, but still pretty good) called High-Performance MySQL |
| 14:05.19 | ctooley | simply tweaking your memory caches will probably improve performance by 2-3X |
| 14:06.09 | ctooley | http://dev.mysql.com/doc/refman/5.0/en/ |
| 14:06.12 | ctooley | The search works well |
| 14:06.56 | jsmith | file: What's wrong with database talk! Databases rock! |
| 14:07.28 | snuff-away | RAM memory SAN storage :) |
| 14:07.52 | jsmith | snuff-away: I've had a terabyte san... they're not that cool |
| 14:08.04 | file | jsmith: expected behavior question... if two RTP streams are bridged in the RTP stack do you expect rtp timeout to work, or not? |
| 14:08.34 | jsmith | file: I'd still expect us to keep tabs on the RTP packets, yes... |
| 14:08.38 | ctooley | Yeah, I'm not really all that happy with our storage situation. We have been working forever to keep up with growth. |
| 14:08.47 | jsmith | ctooley: As did we... as you can imagine. |
| 14:09.42 | ctooley | hehe Our CDR data alone (just since we switched in November) is already 50 terrabytes |
| 14:12.20 | Alric | Glad I don't have that much CDR data. |
| 14:13.06 | ctooley | SQL is for lazy programmers |
| 14:13.23 | Alric | Is that lazy ;) |
| 14:14.09 | snuff-away | mm.. nothin wrong with it when u dont have huge entries.. or blobs etc |
| 14:15.22 | ctooley | Well our soft switch vendor decided that they didn't like extending the CDR table anymore so they decided to add a huge blob at the end of the CDR that they put an XML representation of the entire CDR in. |
| 14:15.34 | jsmith | ctooley: You've gotta be kidding... |
| 14:15.46 | ctooley | without that field our CDRs are about 512 bytes. with it they're over 2K |
| 14:15.52 | ctooley | Yeah, it was genius |
| 14:16.48 | ctooley | "This structured data thing is hard. Let's use a different, FAR SLOWER, structured data mechanism and stick it in the original structured data mechanism." |
| 14:17.19 | Alric | Can you name said manufacturer? :D |
| 14:17.32 | ctooley | And we'd just leave that field out altogether but any new data they start storing is stored in the XML field and not necessarily in the rest of the CDR. |
| 14:17.33 | Alric | Sounds like some places I know... |
| 14:17.39 | ctooley | Veraz Networks |
| 14:18.12 | ctooley | http://www.veraznetworks.com/softswitch.aspx |
| 14:18.18 | Alric | No, not them. Guess there's more than one sad softswitch vendor out there |
| 14:18.34 | ctooley | We've the largest Veraz implementation in North America. |
| 14:18.51 | ctooley | Well, we're working on a replacement for it. |
| 14:19.00 | Alric | Seems like they'd listen to you then when you say you want them to fix their stuff. |
| 14:19.09 | ctooley | Well, we're working on a replacement for it. |
| 14:19.14 | Alric | Yeah. |
| 14:20.07 | ctooley | Sad thing is that we just cut our DMS-250's over to it. We have one DMS around for some features and we decommissioned the other 12. |
| 14:20.40 | ctooley | We had Telelabs switches, Dex switches, DMS switches. Everything got cut to the Veraz. |
| 14:21.18 | ctooley | But, now our CEO has decided that betting the farm on Open Source is a better solution (with a controlled, managed approach of course). |
| 14:21.36 | Alric | So what are you trying to move to? |
| 14:22.31 | ctooley | Alric, you'll see in a few months when we post it on simplified.org |
| 14:22.38 | Alric | Cool |
| 14:22.54 | ctooley | The switch will be up there and freely available. |
| 14:23.17 | Alric | Writing your own or putting together pieces from other OSS projects? |
| 14:23.21 | ctooley | Biggest issue is going to be replacing the EMS/Provisioning system honestly. Switching calls is relatively easy |
| 14:23.27 | ctooley | Yes |
| 14:30.47 | Alric | Argh. SBC DSL not available at the new place :( |
| 14:31.06 | jsmith | Alric: Find a new place |
| 14:31.23 | ctooley | Or find someone better than SBC. |
| 14:31.23 | Alric | jsmith: Can you find me 1400 sq ft house with $0 / month rent? |
| 14:31.31 | ctooley | Alric, where at? |
| 14:31.38 | Alric | Tejas! |
| 14:31.43 | ctooley | Alric, where? |
| 14:31.46 | Alric | Cleburne |
| 14:33.02 | Alric | Requirements: $0 rent $0 mortgage payment :D |
| 14:42.10 | codefreeze | Alric: me too!!! |
| 14:42.35 | Alric | :D |
| 14:51.11 | ctooley | Free is never as free as it sounds. I'm happy to be paying for my house. |
| 14:52.13 | Alric | But it beats the apartment I'm in all over the place. |
| 14:53.29 | Alric | I'd actually love to be in my own little place, but I couldn't find anyone willing to lend money to me because I haven't bought enough stuff on credit before. |
| 14:54.35 | ctooley | I had a similar problem. I couldn't find anyone willing to lend me money because I _have_ bought too much on credit. Which didn't work out so well for my unemployed status. |
| 14:54.42 | ctooley | Thankfully that's clearing up now. |
| 14:54.44 | *** join/#asterisk-doc fakhir (n=Fakhir@unaffiliated/fakhir) |
| 14:54.58 | Alric | Oh, and I had no established income because I was a full time student until May of this year. |
| 14:55.13 | Alric | So my W2 showed an abysmally low income. |
| 14:55.18 | ctooley | Alric, that's no reason not to give you loads of money. :) |
| 14:55.33 | Alric | Yeah, its rather annoying. |
| 14:55.55 | Alric | I see classmates of mine getting all kinds of credit, houses, etc extended to them, and I know I'm a million times better off financially than they are, but I can't get anything. |
| 14:58.23 | Alric | In other news, I have slow query log enabled now :D |
| 14:58.45 | ctooley | that'll help |
| 15:00.31 | Alric | I think its NFS though. We're seeing much better database results coming off local drives. |
| 15:00.44 | Alric | But then we have software raid that may be problematic. It never ends.. |
| 15:02.50 | ctooley | software raid may not be a problem. |
| 15:03.09 | ctooley | depending on your hardware controller it may actually improve performance. |
| 15:03.12 | Alric | The guy running the tests is reporting that delete statements are taking longer on local drive than over NFS for whatever reason. |
| 15:03.26 | Alric | hardware controller? its software raid though. no hardware... |
| 15:03.36 | Alric | Oh. Drive controller? |
| 15:03.48 | Alric | Not RAID controller? |
| 15:13.49 | ctooley | Well, if your drive controller is a raid controller, then yes. But mostly I meant sometimes software raid is faster than hardware raid even if you have a hardware raid controller. |
| 15:14.15 | jsmith | Especially for writes on a RAID 5 controller |
| 15:15.42 | ctooley | jsmith, some writes are faster with hardware raid 5 than software raid 5. But, usually, yes RAID 5 is slower than other types of raid. |
| 15:16.48 | ctooley | you should be ok |
| 15:17.13 | ctooley | of course drive performance is a YMMV kind of thing. It depends on the drives, the caches, etc |
| 15:17.17 | Alric | Still doesn't explain why deletes happen faster over NFS than local. |
| 15:17.19 | Alric | :( |
| 15:17.42 | ctooley | well, it depends on what the NFS mount is. |
| 15:17.49 | Alric | NetApp |
| 15:18.07 | ctooley | Generally network performance is faster than harddrives anyway (at least on a good GigE). |
| 15:18.22 | Alric | I do know its FastE, not GigE though. |
| 15:18.31 | ctooley | But, it depends on how it's set up, what the NetApp has is running etc. |
| 15:18.50 | Alric | Yeah. |
| 15:19.20 | file | so here it comes... the sound of drums! |
| 15:22.03 | jsmith | ~drumroll |
| 15:24.20 | jsmith | jbot: drumroll is <action> starts a drumroll |
| 15:24.21 | jbot | okay, jsmith |
| 15:24.24 | jsmith | ~drumroll |
| 15:24.25 | jbot | ACTION starts a drumroll |
| 15:24.38 | Alric | ~lart blitzrage |
| 15:24.38 | jbot | nukes blitzrage with a single large nuke |
| 15:24.40 | jsmith | jbot: drumroll $who is <action> starts a drumroll for $whoo |
| 15:24.41 | jbot | okay, jsmith |
| 15:24.42 | ctooley | the suspense is killing me |
| 15:24.47 | jsmith | jbot: no, drumroll $who is <action> starts a drumroll for $who |
| 15:24.48 | jbot | jsmith: okay |
| 15:24.52 | jsmith | ~drumroll file |
| 15:24.53 | jbot | ACTION starts a drumroll for jsmith |
| 15:24.57 | jsmith | Doh! |
| 15:25.06 | jsmith | jbot: no, drumroll $bob is <action> starts a drumroll for $bob |
| 15:25.07 | jbot | jsmith: okay |
| 15:25.09 | jsmith | ~drumroll file |
| 15:25.10 | jbot | ACTION starts a drumroll for file |
| 15:25.14 | jsmith | w00t! |
| 15:26.18 | file | awwwwww |
| 15:28.23 | jsmith | file: So, what are the drums all about? |
| 15:28.34 | file | song reference |
| 15:28.48 | file | :D |
| 15:28.58 | jsmith | Oh... missed that one |
| 15:29.00 | ctooley | Ugh. I thought it was some big thing you were announcing |
| 15:29.04 | file | oh, no |
| 15:29.19 | file | I won't talk about anything in that area... |
| 15:29.19 | file | yet. |
| 15:30.10 | ctooley | that's what you said the other day... hence we were rolling drums. |
| 15:37.04 | file | can't you feel my heart beat keeping perfect time? |
| 15:37.08 | file | and all because he... |
| 15:37.13 | file | touched me, he looked at me and stared |
| 15:37.15 | file | yes he bumped me |
| 15:37.17 | file | my heart was unprepared |
| 15:37.23 | file | when he tapped me... and knocked me off my feet |
| 15:54.01 | Alric | Oh. Duh. Call recording. |
| 15:59.32 | blitzrage | I've been larted?! oh but why?! |
| 15:59.50 | Alric | ~wake blitzrage |
| 15:59.51 | jbot | ACTION throws a barrel-full of ice water on blitzrage and shouts "GOOD MORNING!!!!" |
| 16:00.12 | blitzrage | what a crappy way to wake up |
| 16:01.13 | Alric | On today's agenda: Asterisk Clustering! |
| 16:03.54 | jsmith | Alric: Learn OpenSER, learn DUNDi, and learn where to use which. |
| 16:04.09 | Alric | Seen BioCluster? |
| 16:05.40 | jsmith | Nope... is it like Qlusters? |
| 16:06.14 | Alric | No idea. Its a clustering thing built for Asterisk though. |
| 16:11.47 | Alric | Required Java though. |
| 16:14.49 | *** join/#asterisk-doc codefreeze (n=steve_mu@216.166.159.235) |
| 16:14.49 | *** join/#asterisk-doc snuff-away (i=snuff@220-253-41-30.VIC.netspace.net.au) |
| 16:14.49 | *** join/#asterisk-doc snuff-work (n=na@61.29.30.137) |
| 16:15.30 | jsmith | Yuck |
| 16:15.36 | jsmith | That's a deal-killer right there in my book |
| 16:17.51 | codefreeze | jsmith: deal-killer? |
| 16:18.40 | jsmith | codefreeze: Alric was telling me about an Asterisk cluster software that required Java... |
| 16:19.07 | blitzrage | the word 'java' to me means 'unscalable' |
| 16:19.09 | codefreeze | java == bad? |
| 16:19.23 | codefreeze | ahhh |
| 16:19.31 | jsmith | codefreeze: In my book, yes... too much experience with it to still like it |
| 16:19.33 | Alric | Thats kind of my opinion as well. |
| 16:19.45 | blitzrage | java should live on webpages, and that's it |
| 16:20.10 | Alric | Well-done Java can probably be very nice. |
| 16:20.18 | Alric | In theory. |
| 16:20.23 | blitzrage | ok, I'm running down to the basement to get an inventory of the training equipment and hoping I don't have to do it again |
| 16:20.26 | Alric | I've never seen anything that brings that beyond theory though :D |
| 16:20.46 | blitzrage | Alric: in theory... I've done java programming in school -- it's not very nice to program in. Not the most intuitive language in the world... |
| 16:20.48 | codefreeze | by scalable, do you mean that for big stuff, it's such a huge mem hog, that it endangers VM? |
| 16:20.56 | blitzrage | codefreeze: basically... ya :) |
| 16:21.11 | blitzrage | anything big tends to use a ton of memory... and I've never seen anything in java be really "quick" |
| 16:21.30 | blitzrage | and certainly not quick enough to distribute thousands of calls in real time |
| 16:21.42 | Alric | I don't think I've ever seen a Java-based program that didn't have memory leaks. |
| 16:22.27 | codefreeze | The things I like about java: a. a really, really, nice library to work from b. simplified object model (as opposed to complicated C++) |
| 16:22.54 | blitzrage | I hated learning Java.... it seemed like you need to already know java to be able to use java.... |
| 16:22.54 | Alric | set-variable=long_query_time=1 |
| 16:22.58 | jsmith | Alric: Why? Java has garbage collection |
| 16:23.00 | Alric | Is that a bad long_query_time? |
| 16:23.19 | blitzrage | seemed like I needed to know so many libraries before I could even start writing something |
| 16:23.25 | jsmith | 1 second? Depends on the type of queries you're running |
| 16:23.30 | Alric | jsmith: Don't understand the question... |
| 16:24.00 | jsmith | Alric: Obviously not :-) |
| 16:24.05 | Alric | jsmith: I just ask because I put that into effect like an hour ago and the log shows nothing. Seems like if we're having problems there should be log entries :D |
| 16:24.27 | Alric | Can you handle a threaded conversation? hehe. |
| 16:25.51 | Alric | Hrm. I just ran a query that took 5.5 seconds to complete. No log entry. |
| 16:28.50 | ctooley | Alric, you restarted MySQL? |
| 16:28.58 | ctooley | slow query log takes a restart |
| 16:31.26 | Alric | Yeah |
| 16:31.36 | Alric | I found out what happened. I put those lines in the wrong place in my.cnf |
| 16:33.38 | ctooley | ic |
| 16:34.37 | ctooley | someone just created a bunch of pins on our calling card platform that are 2 digits longer than the rest of the pins in the database. Now we're supposed to support variable length pins and have the code to do it out by the end of the day. |
| 16:35.13 | Alric | Ouch. |
| 16:35.20 | Alric | Loading CDRs is taking time. |
| 16:35.57 | ctooley | how many and how many at once? |
| 16:36.02 | Alric | Not sure. |
| 16:36.11 | Alric | I'm headed to lunch, starving. Will investigate more when I get back. |
| 16:36.34 | Alric | # Query_time: 21 Lock_time: 0 Rows_sent: 0 Rows_examined: 0 |
| 16:45.15 | blitzrage | jsmith: looks like I don't have the server here |
| 16:45.39 | file | ooh it's a blitzrage |
| 16:45.50 | blitzrage | it sure is! |
| 17:05.50 | *** join/#asterisk-doc jsmith (n=jsmith@000-143-916.area3.spcsdns.net) |
| 17:05.50 | *** mode/#asterisk-doc [+o jsmith] by ChanServ |
| 18:11.23 | jsmith | Alric: Now you know the difference between "somebody who knows about databases" and a "DBA" |
| 18:13.00 | Alric | Plumber charges a lot more? ;) |
| 18:13.07 | ctooley | yeah, and know a lot more. |
| 18:18.11 | jsmith | ctooley: My point exactly... both can hook pipes together, but when the toilets are backing up, you don't call the pipefitter... |
| 18:19.08 | Alric | Wow |
| 18:19.18 | Alric | I just logged into a very old PBX. I say DBGet() calls :D |
| 18:19.25 | Alric | s/say/see |
| 18:19.26 | jsmith | Alric: That's not old... |
| 18:19.34 | Alric | It is for me. |
| 18:19.47 | Alric | 0.7? |
| 18:19.50 | Alric | Not 0.7.1? |
| 18:19.59 | jsmith | I guess I shouldn't announce that publicly, should I |
| 18:20.23 | Alric | I say that because 0.7 had a GotoifTime bug, and a time-based #include bug :D |
| 18:20.29 | jsmith | Well, I shouldn't even say *I* still have... *a company I used to work for* has |
| 18:20.35 | Alric | That was recognized when it was released, and fixed the next day with 0.7.1. |
| 18:20.42 | jsmith | Alric: Yeah, which I hacked around manually |
| 18:20.51 | Alric | Instead of waiting a day? :D |
| 18:22.50 | jsmith | Time was of the essence |
| 18:23.08 | jsmith | To be honest, I think I did upgrade them to something like 0.8 or something like |
| 18:23.26 | Alric | ah |
| 18:33.37 | Alric | So we have a table with 13 indexes. |
| 18:41.48 | jsmith | Cool... let me guess... thirteen columns? |
| 18:42.10 | Alric | 49 columns |
| 18:42.15 | jsmith | OK, not so bad then. |
| 18:42.26 | jsmith | Is that one of your problem queries? |
| 18:42.37 | jsmith | Have you looked at the output of EXPLAIN? |
| 18:42.42 | Alric | Well, inserting and deleting from that DB is creating a problem, I suspect. |
| 18:42.53 | Alric | how do you even use explain? |
| 18:42.58 | Alric | explain <query> ? |
| 18:43.29 | jsmith | Yup. |
| 18:44.04 | Alric | no :D |
| 18:44.08 | jsmith | ~wobble |
| 18:44.13 | Alric | ~lart blitzrage |
| 18:44.13 | jbot | burns blitzrage to a crisp with a laser |
| 19:00.32 | Alric | jbot: wobble is <action> wobbles like file |
| 19:00.33 | jbot | Alric: okay |
| 19:00.37 | Alric | ~wobble |
| 19:00.37 | jbot | ACTION wobbles like file |
| 19:58.26 | jsmith | ~wobble Alric |
| 19:58.55 | Alric | ~lart jsmith |
| 19:58.55 | jbot | sends a legion of lawyers after jsmith's head |
| 19:58.59 | jsmith | jbot: wobble $bob is <action> pushes $bob so that he wobbles like file |
| 19:58.59 | jbot | okay, jsmith |
| 19:59.01 | jsmith | ~wobble Alric |
| 19:59.02 | jbot | ACTION pushes Alric so that he wobbles like file |
| 19:59.17 | Alric | ~drumroll jsmith |
| 19:59.17 | jbot | ACTION starts a drumroll for jsmith |
| 19:59.18 | jsmith | Alric: You do now! |
| 19:59.28 | blitzrage | :) |
| 19:59.36 | Alric | ~lart blitzrage |
| 19:59.36 | jbot | decapitates blitzrage conan the destroyer style |
| 19:59.58 | blitzrage | conan should be uppercase :) |
| 20:00.29 | Alric | What do Canadians know about grammar and spelling? |
| 20:00.40 | Alric | colour, centre, cheque, the list goes on. |
| 20:03.24 | blitzrage | honour |
| 20:03.28 | blitzrage | :) |
| 20:14.47 | Alric | Exactly. |
| 22:33.38 | blitzrage | jsmith-away: ping? |
| 23:27.13 | jsmith-away | blitzrage: Pong? |
| 23:28.28 | blitzrage | jsmith-away: you're going to get the hard drives when you're in SLC next week right? |
| 23:32.34 | jsmith-away | blitzrage: Roger, wilco. |
| 23:32.59 | blitzrage | ok cool. Let me know when you get the data off the drives and I'll put a copy on my desktop too |
| 23:33.01 | jsmith-away | blitzrage: I'm also going to be fixing the server (like you fix a cat?) once and for all, or else bringing it back with me to replace with something local. |
| 23:33.11 | blitzrage | ok coolio! |
| 23:33.15 | blitzrage | keep me posted |
| 23:33.20 | jsmith-away | Roger, roger. |
| 23:33.47 | jsmith-away | While you're trekking across vast oceans of nothingness in western Canadia, I'll be slaving away trying to recover every last bit of your files. |
| 23:37.54 | file | awwww how nice |
| 23:41.45 | blitzrage | well that's nice :) |
| 23:42.51 | jsmith | Ah, now to go mow the lawn^H^H^H^ three foot weeds in my front yard before it gets any darker. |
| 23:43.09 | blitzrage | mowing the lawn is fun |
| 23:43.41 | jsmith | It is if it's grass... if it's acres of three-foot-high weeds, it's not. |