It seems the mantra that we hear from clients most often is "...[it] must be a database problem." The reality is that it almost never is, in fact, a "database problem!" It seems that the DBA is most often "guilty until proven innocent," rather than the other way around. At first, I thought maybe this was how MySQL was viewed because of the whole open-source stigma, but I have seen the same reaction on other DBMS platforms. After chatting with Oracle, SQL Server, DB2, etc., DBA's, I heard the same thing repeated over and over...
Let me give you some of the examples I have seen. Maybe you can identify with some of these. Either way, perhaps it will generate a little smile. Naturally, this will be a short list of some of the problems and not the whole list:
Not too long ago, I was asked to troubleshoot a "problem" with the database where an ESB server could not connect to a MySQL server. I was told there was an issue with the database since they were getting connection issues! I logged into the VPN and immediately tried to login via the CLI into MySQL from localhost. No problem -- as I expected. Then, I tried to login from another machine via TCP/IP into the same database server and again no problem. Since I did not have direct access to the ESB server, I had another techie try a telnet from the same machine and they got a response! I double-checked the MySQL user table and it was set to allow connections from the ESB server! After having everything check out, I had them send me the XML config file for the ESB server to see the connect string and guess what!?!? The connect string was for a SQL Server in another country that was not even on this network!
The person who set it up copied a config file from another server and missed changing significant portions of the config! You would think the client would blush at this point and apologize, but that isn't what happened. They still insisted it was a MySQL problem! I was shocked! I had to copy the configuration section and send it to them color-coded and ask why it was trying to connect to a server in abother country that wasn't even on this network, to a database that was a SQL Server database, on a SQL Server port with MySQL configuration specifics! I think the ESB person finally saw the problem. No wonder why there was a problem! Needless to say, "database problem" solved!
There is so much bias out there that sometimes others are blinded to the obvious in their haste to blame someone else! I presume the same cry can be heard from Development Teams, Unix administrators, and so on...
I have also seen a number of networking problems mis-diagnosed as database issues. Perhaps you have been there too. I have seen ailing network cards that were becoming intermittent cause issues (not to mention switches with bad ports). While these hit-and-miss errors are hard to diagnose, they are rarely MySQL problems. But, as always, the other tech people responsible for those platforms have learned the mantra -- "got to be a database problem..."
Another common issue is when an application person decides to copy the JBoss / Tomcat configuration over from a Dev box to a new UAT server and forgets that we keep user access permissions different on the various environments for security reasons. As you can imagine, when they start up and get a connection error, it is time to call the DBA and figure out what is wrong with the database! I have learned to make my first request be for seeing their configuration file!
Anyway, I could rant on and on, but I was curious whether anyone else noticed the same pattern? Surely, it isn't just me'! Am I the only DBA that gets called in every so often in the middle of the night to diagnose someone else's problem? I sure hope not! Maybe "misery" really does love company...
A few years back when being engaged in a new position, we were wondering what backup method would be used. We assumed we would be using something like Zmanda to manage backups centrally for all servers. Boy, were we in for a surprise! The enterprise company was using EMC's BCV solution! None of us were quite sure how this would integrate with MySQL!
After doing some research and talking with the "BCV guy" we learned that BCV has to establish a "pair" with a drive of the exact same size. It is a sort of running mirror of the drive for those of you who are not familiar with it. Then once the backup and the data are synced, you "break the mirror." Pretty simple idea, but how do we guarantee consistency? That was the problem!
We talked with MySQL and asked if they had support for BCV and the technician acted kind of surprised as well and informed us they didn't. Now what? We had to create a custom solution!
After a number of email exchanges, MySQL AB suggested we go with a utility called ShellSQL. While this is an awesome utility, it requires the DBA to learn one more thing and maintain it. The boss was not real happy with this solution, so on we went...
Now you may be thinking, why not just pass the "-e" option to the mysql client. While we eventually figured out a way to make that work, our first concern was that using multiple statements in this manner would not work for us.
We needed to lock all of the tables, split the BCV, and then unlock the tables from Bash. The idea was something like this:
mysql -e "FLUSH TABLES WITH READ LOCK"
./split_bcv.ksh
mysql -e "UNLOCK TABLES"
The problem naturally is that when the client disconnects after the lock, MySQL unlocks all of the tables, thus impairing our ability to guarantee a consistent backup.
The solution for us however was in MySQL's "system" command! We just had to string all of the commands together into a sort of "wrapper" script using MySQL to fire the split. Below is that script:
#!/bin/sh
# bcv_backup.sh
#
# Simple Bash script to run BCV Backups
# Valcora: http://www.valcora.com
#
# Configuration
MYSQL="/usr/bin/mysql"
MYSQL_USER="backup"
MYSQL_PASSWORD="mypass"
MYSQL_SOCKET="/tmp/mysql.sock"
BCV_SCRIPT="/opt/emc/BCV_split.ksh"
CMD="FLUSH TABLES WITH READ LOCK; system '$BCV_SCRIPT'; UNLOCK TABLES;"
BACKUP_LOG="/var/logs/cps.log"
# Redirect all output to backup log
exec &>$BACKUP_LOG
echo "Beginning BCV Backups..."
echo "Began: `date`"
# Actual MySQL Client Command That Does It All
$MYSQL -vvv -u$MYSQL_USER -p$MYSQL_PASSWORD -S $MYSQL_SOCKET -e "$CMD"
echo "Ended: `date`"
echo
chown mysql:mysql $BACKUP_LOG
# Reset stdout and stderr back to screen, not logfile
exec >&-
This script would fire the split script while the tables were locked and then upon completion, would unlock the tables.
Naturally, we wanted to keep a log of the activities as well.
We ran this solution by MySQL AB and they agreed there should be no problem doing it that way!
Well, we have been running this for over two years now and not a single problem. We have had on a few occassions needed to restore from the BCV and it has always been perfect!
In case you are interested, below are examples of the BCV scripts for the establish and split:
#!/bin/ksh
# BSV_establish.ksh
## ESTABLISH Pairs **********************************
cd /opt/emc
. ./symcli_path
symmir -g SAN_dev est -full -nop
#!/bin/sh
. /opt/emc/symcli_path
let COUNT=0
echo Run EMC symmir command and check for return code 0
echo
while true
do
symmir verify -g SAN_dev
RC=`echo $?`
if [ $RC = 0 ]
then
echo
echo
echo " The return code is 0, the BCVs are all established. Exit with return code 0 "
exit 0
fi
sleep 600 # sleep for 10 minutes
let COUNT=COUNT+1
echo " --> Pass $COUNT complete. The BCVs are not established."
if [ "$COUNT" = "50" ]
then
echo
echo
echo " The BCVs are not established after $COUNT passes. Exit with return code 8. "
exit 8
fi
done
echo
echo " Unexpected error. Exit with return code 12. "
exit 12
The BCV_establish.ksh script is called an hour or so before the MySQL script is scheduled so that there is sufficient time for the drives to sync up. Then the MySQL script breaks the mirror and our backup is complete. As you can imagine, all of this is scheduled for off-hours.
Anyway, if you find yourself faced with a similar dilemma, hopefully this may give you some ideas...
Have you ever tried to start a server like MySQL and been amazed to see an error that the port is already in use? You rack your brain and try to figure out what it would be to no avail. Sometimes you do a "ps" in Linux and don't even see anything that you think would be using the port. Well, forutantely, there are some tricks to help you find out without doing a reboot. If it is a production server, a reboot may not be an option anyway!
Below are some methods to help. We will start by looking at the "fuser" utility provided with many Linux distros:
This example shows a simple check of everything using port 80. What you see above is a list of PIDs that are using that port. Now we could probably just do a simple "ps" to figure out what it is. You might also want to get more info by doing something like the following to determine from where it is running:
Many of us at Valcora were "fortunate" to start our tech careers in a small web development shop where we were expected to be "jack-of-all-trades." We say "fortunate" because at the time, it doesn't seem so great. Looking back, however, it is clear that we got a lot of experience that was invaluable that way.
We were expected to be Linux System Administrators, handle user accounts, Linux installs, manage DNS, install/configure/manage Apache, do custom PHP programming, MySQL Database Administrator, search engine optimization, and on and on...
As we have worked with various companies over the years, we all have realized that not everyone else grew up in that kind of environment. The normal that we have encountered is highly specialized individuals who know one thing and know it fairly well. While there is absolutely nothing wrong with that in many cases, it can be a crutch and a short-coming for anyone wanting to be a senior-level MySQL DBA in our opinion. Why? Well, frankly, because a senior-level DBA should know a lot more than just MySQL.
After chatting with the guys here at Valcora, we all realized that we have been called upon in our careers to do pull some fairly heavy Linux tricks out of our "bag of tricks." Below are just a few of the things we have had to do and honestly, we are not sure a specialized junior would know what to do in most of these cases.
We were reminiscing and thought of the time a client wanted to see the queries that are passing through their production MySQL server. At this point, a junior might be tempted to say, well let's turn on the general query log, but that is not an option when you are running MySQL 4.1 and it would require a server restart! The DBA who had setup the server did not symlink the general query log to /dev/null so that it could be un-linked and a "flush logs" performed to start capturing logs. (Some senior DBAs might have missed that trick. )
The only option was to try and capture statements with some other method. After confirming with the client that they needed SELECT statements as well as writes (DML), we came to the conclusion that we were going to have to "sniff" for those. Doing a poll of the "SHOW PROCESSLIST" every second was not a n option since so many would be missed. So, we decided to use tcpdump and capture the queries with some serious grep statements. Thinking that was the job of the Linux System Administrator? Guess again. It was the DBA's job in this company.
Right about now, if you are thinking that is too heavy duty for a MySQL DBA, remember we are talking about real senior-level DBA's.
We were able to capture the data for a fixed time period and then massage it with more Linux commands into a report of the queries. For those of you who know about it, this was before the days of mysqlsniffer, which is a great little utility to do basically the same thing! We wish we had it at that time and it would have made our job easier!
On other occassions, we all seen at one time or another a problem where we try to start MySQL and Linux reports that the port is already in use. Now, a reboot, again, is a simple solution to this problem. But, in some cases, a reboot is not permitted without management approval and if they happen to be running anything else on that server, good luck getting downtime to perform one. Since there is a process that has that port, we need to find out what is holding onto it. (That is a rather straight forward process which we will detail in another blog coming soon.) Again, Linux skills to the rescue. Find the process and more than likely it will be one that you can kill since it probably shouldn't be using a port used for MySQL such as 3306 and then start MySQL up with no problems. No waiting for approvals or having to explain to some manager, why you need to reboot the server.
Custom scripting is another area that deserves mention. We all recalled how many Bash, Perl, and PHP scripts we have written over the years to perform some maintenance task in MySQL. In the early days, MySQL did not always have scripts/utilities like mysqlcheck for example. And speaking of that, one of us commented how we decided to use mysqlcheck to analyze a production server that had been rebooted in a not-so-graceful manner by a System Administrator without shutting down MySQL properly. This was like a power down by pulling the plug! Anyway, a few of the InnoDB tables were crashed and mysqlcheck just skipped them and never even reported a problem. Looking at its "report" made us think that everything was ok, but we knew better.
Bash scripting to the rescue. We crawled through every database and table and performed "CHECK TABLE" on each with a simple Bash script. We submitted a bug report to MySQL and it is supposed to have been resolved by now. While it probably is safe to use the newer version of mysqlcheck, some of us old-timers are still cautious enough to think our simple Bash script found the problem for sure and is likely to always find the problem, so why change to something that has proven to have problems?
One of the recurring things, we all joked about was how many times we have battled library issues when installing MySQL. We have fought with Perl DBI and DBD libs as well as Linux libraries such as glibc and such when compiling MySQL from source. Yes, some of us still like to compile from source for a variety of reasons, though we also love binaries.
In some companies, it is also helpful to be able to diagnose firewall issues. We have seen mis-configured firewall rules before where someone inadvertantly missed a rule and the application server could not talk with the database server. Since in most companies, the general assumption is that "it must be a database problem," (The senior DBAs are nodding their heads now!) it is critical to be able to diagnose networking issues since we are often guilty until proven innocent! If you as a DBA have to wait on a networking person to clear you, good luck! The sooner you can troubleshoot and discover latency or connectivity issues in the network, the sooner you get off the "hot seat" and look like a hero in finding the problem. Most juniors in this case, are probably thinking "But, that is not my job! I am the DBA!" The old-timers realize that it takes more than MySQL skills!
We have also seen development teams establish connections to the server that seem to terminate unexpectedly. After having MySQL be blamed by the development team, it took some special skills to start examining the JBoss and Tomcat configurations. Naturally, the individuals responsible for those applications also afrgued it was a MySQL "problem." But we knew better! As you can expect, the problem was with the configuration of connection pooling and timeouts in their configurations. When we notified them of what needed to be changed and why it was a problem, they finally conceded that this was the real problem. We tested it and voila, problem solved! Again, not a MySQL problem, but it was critical for us to diagnose it and clear our name.
Anyway, we could go on and on, but surely you get our point! To be a real DBA, we think you have to be well-rounded and be able to perform a lot of Linux Administrator skills to survive in a LAMP environment...
If you are not a senior DBA, don't worry. Find yourself a good senior and partner with them. Soak up all you can from them like a sponge. Then, one day, perhaps you too can call yourself a senior...
If you are a senior-level DBA, find yourself a willing junior to take under your wing and return the favor...
Have you ever needed to determine details about a particular server that maybe you have never seen before? Well, in Linux, there is a great utility that not that many novice users have ever used. It is called "dmidecode."
From the "man" entry for dmidecode:
dmidecode is a tool for dumping a computer’s DMI (some say SMBIOS) table contents in a human-readable format. This table contains a description of the system’s hardware components, as well as other useful pieces of information such as serial numbers and BIOS revision. Thanks to this table, you can retrieve this information without having to probe for the actual hardware. While this is a good point in terms of report speed and safeness, this also makes the presented information possibly unreliable.
The DMI table doesn’t only describe what the system is currently made of, it also can report the possible evolutions (such as the fastest supported CPU or the maximal amount of memory supported).
SMBIOS stands for System Management BIOS, while DMI stands for Desktop Management Interface. Both standards are tightly related and developed by the DMTF (Desktop Management Task Force).
...
...
DMI TYPES
The SMBIOS specification defines the following DMI types:
Type Information
----------------------------------------
0 BIOS
1 System
2 Base Board
3 Chassis
4 Processor
5 Memory Controller
6 Memory Module
7 Cache
8 Port Connector
9 System Slots
10 On Board Devices
11 OEM Strings
12 System Configuration Options
13 BIOS Language
14 Group Associations
15 System Event Log
16 Physical Memory Array
17 Memory Device
18 32-bit Memory Error
19 Memory Array Mapped Address
20 Memory Device Mapped Address
21 Built-in Pointing Device
22 Portable Battery
23 System Reset
24 Hardware Security
25 System Power Controls
26 Voltage Probe
27 Cooling Device
28 Temperature Probe
29 Electrical Current Probe
30 Out-of-band Remote Access
31 Boot Integrity Services
32 System Boot
33 64-bit Memory Error
34 Management Device
35 Management Device Component
36 Management Device Threshold Data
37 Memory Channel
38 IPMI Device
39 Power Supply
Go ahead and give it a try. You may be surprised at the plethora of information available to you with such a simple command.
/usr/sbin/dmidecode
Below is the output of "dmidecode" on a small desktop server:
# dmidecode 2.7
SMBIOS 2.4 present.
24 structures occupying 3009 bytes.
Table at 0x000F0000.
Handle 0x0000, DMI type 0, 24 bytes.
BIOS Information
Vendor: Phoenix Technologies, LTD
Version: 5.08
Release Date: 04/27/2007
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 512 kB
Characteristics:
PCI is supported
PNP is supported
APM is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/360 KB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 KB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 5.8
Handle 0x0001, DMI type 1, 27 bytes.
System Information
Manufacturer: Compaq-Presario
Product Name: GC662AA-ABA SR5113WM
Version:
Serial Number: CNH720064C
UUID: 80DE8209-206F-1210-BE87-8ECDE0505874
Wake-up Type: Power Switch
SKU Number: GC662AA#ABA
Family: 103C_53316J
Handle 0x0002, DMI type 2, 8 bytes.
Base Board Information
Manufacturer: ASUSTek Computer INC.
Product Name: IVY
Version: 1.01
Serial Number: MS1C74S30100479
Handle 0x0003, DMI type 3, 17 bytes.
Chassis Information
Manufacturer: Hewlett-Packard
Type: Desktop
Lock: Not Present
Version: Chassis Version
Serial Number: BB0001
Asset Tag:
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Handle 0x0004, DMI type 4, 35 bytes.
Processor Information
Socket Designation: Socket AM2
Type: Central Processor
Family: Athlon 64
Manufacturer: AMD
ID: B1 0F 06 00 FF FB 8B 17
Signature: Extended Family 0, Model B, Stepping 1
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (Fast floating-point save and restore)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Hyper-threading technology)
Version: AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
Voltage: 1.2 V
External Clock: 200 MHz
Max Speed: 3700 MHz
Current Speed: 1900 MHz
Status: Populated, Enabled
Upgrade: Socket 940
L1 Cache Handle: 0x0008
L2 Cache Handle: 0x0009
L3 Cache Handle: Not Provided
Serial Number:
Asset Tag:
Part Number:
Handle 0x0005, DMI type 5, 20 bytes.
Memory Controller Information
Error Detecting Method: 64-bit ECC
Error Correcting Capabilities:
None
Supported Interleave: One-way Interleave
Current Interleave: One-way Interleave
Maximum Memory Module Size: 1024 MB
Maximum Total Memory Size: 2048 MB
Supported Speeds:
70 ns
60 ns
50 ns
Supported Memory Types:
DIMM
Memory Module Voltage: 2.9 V
Associated Memory Slots: 2
0x0006
0x0007
Enabled Error Correcting Capabilities:
None
Handle 0x0006, DMI type 6, 12 bytes.
Memory Module Information
Socket Designation: A0
Bank Connections: 0
Current Speed: 6 ns
Type: DIMM
Installed Size: 512 MB (Single-bank Connection)
Enabled Size: 512 MB (Single-bank Connection)
Error Status: OK
Handle 0x0007, DMI type 6, 12 bytes.
Memory Module Information
Socket Designation: A1
Bank Connections: 2
Current Speed: 6 ns
Type: DIMM
Installed Size: 512 MB (Single-bank Connection)
Enabled Size: 512 MB (Single-bank Connection)
Error Status: OK
Handle 0x0008, DMI type 7, 19 bytes.
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 128 KB
Maximum Size: 128 KB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Data
Associativity: 4-way Set-associative
Handle 0x0009, DMI type 7, 19 bytes.
Cache Information
Socket Designation: L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 512 KB
Maximum Size: 512 KB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 4-way Set-associative
Handle 0x000A, DMI type 9, 13 bytes.
System Slot Information
Designation: PCI1
Type: 32-bit PCI
Current Usage: In Use
Length: Short
ID: 1
Characteristics:
5.0 V is provided
PME signal is supported
Handle 0x000B, DMI type 9, 13 bytes.
System Slot Information
Designation: PCI2
Type: 32-bit PCI
Current Usage: Available
Length: Short
ID: 2
Characteristics:
5.0 V is provided
PME signal is supported
Handle 0x000C, DMI type 9, 13 bytes.
System Slot Information
Designation: PCIEX16
Type: x16 PCI Express
Current Usage: Available
Length: Short
Characteristics:
5.0 V is provided
PME signal is supported
Handle 0x000D, DMI type 9, 13 bytes.
System Slot Information
Designation: PCIEX1_1
Type: x1 PCI Express
Current Usage: Available
Length: Short
Characteristics:
5.0 V is provided
PME signal is supported
Handle 0x000E, DMI type 13, 22 bytes.
BIOS Language Information
Installable Languages: 3
n|US|iso8859-1
n|US|iso8859-1
r|CA|iso8859-1
Currently Installed Language: n|US|iso8859-1
Handle 0x000F, DMI type 16, 15 bytes.
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 2 GB
Error Information Handle: Not Provided
Number Of Devices: 2
Handle 0x0010, DMI type 17, 27 bytes.
Memory Device
Array Handle: 0x000F
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 512 MB
Form Factor: DIMM
Set: None
Locator: A0
Bank Locator: Bank0/1
Type: DDR2
Type Detail: None
Speed: 667 MHz (1.5 ns)
Manufacturer: 7F7F7F7F7F510000
Serial Number: None
Asset Tag: None
Part Number: 64T64000HU3SB
Handle 0x0011, DMI type 17, 27 bytes.
Memory Device
Array Handle: 0x000F
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 512 MB
Form Factor: DIMM
Set: None
Locator: A1
Bank Locator: Bank2/3
Type: DDR2
Type Detail: None
Speed: 667 MHz (1.5 ns)
Manufacturer: 7F7F7F7F7F510000
Serial Number: None
Asset Tag: None
Part Number: 64T64000HU3SB
Handle 0x0012, DMI type 19, 15 bytes.
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0003FFFFFFF
Range Size: 1 GB
Physical Array Handle: 0x000F
Partition Width: 0
Handle 0x0013, DMI type 20, 19 bytes.
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0001FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x0010
Memory Array Mapped Address Handle: 0x0012
Partition Row Position: 1
Handle 0x0014, DMI type 20, 19 bytes.
Memory Device Mapped Address
Starting Address: 0x00020000000
Ending Address: 0x0003FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x0011
Memory Array Mapped Address Handle: 0x0012
Partition Row Position: 1
Handle 0x0015, DMI type 32, 11 bytes.
System Boot Information
Status: No errors detected
Handle 0x0016, DMI type 11, 5 bytes.
OEM Strings
String 1: bid=73NAv3PrA1;PROD_MSWORKS;DLED;IS.N60d;ACPwrFail=Off;Chan=Reta
String 2: il;CPUFan=On;DVDRW;LegacyFloppy=No;TVout=NTSC;PCBRAND=Presario;O
String 3: S=MSV;R_WM;LScribe;DVDP_STD;Vos.H;PROD_MSOFFHST;MDVD_B;RC_B;FPA=
String 4: H;C_MAR;.G4;##HPCPC=00000000<90000006020000000420000253514130040
String 5: 000010001000;5;:0665<;85>18>1<2=1:<55>?4;;=?=19:<8494;>:8011<=31
String 6: 953=?76?>378139;594701:=;34:;55;9128<7937==0<722<:<1:2489>:088=6
String 7: :?1;2>8=8>12691>>286:9?;4454>3<3>89909>=738375;02951<;>=??2?70>7
String 8: 5;04<815:33<20846?312127;?24876>7488457<0;0?39>9;?407;8;8;09>=;=
String 9: =>231>;?456:100000006;00000000002000840515?454=435<49434=2340534
String 10: 7594>444?47535020000000000000000000000000000000000000000?24?4195
String 11: 4<8?4243:463542:9034;??09<31;8951=>:><6>3291=35:7;:7?<0;=973478<
String 12: 4:062629<>53103<<=4651<3499:7?769::98;357697=:3483>07=6;>1<1?<>7
String 13: <817?5586>79?5:5?19<87:>=6507148017=835>552096;714776===1=59:5:9
String 14: ;7?16>;910;64?;=21?;7975:6660><>729>:9<98<5<=991>7?7>
String 15:
String 16:
String 17:
String 18:
String 19:
String 20:
String 21:
String 22:
String 23:
String 24:
String 25:
String 26:
String 27:
String 28:
String 29:
String 30:
String 31:
String 32:
Handle 0x0017, DMI type 127, 4 bytes.
End Of Table
Many users are aware that you can get a more basic overview in Linux by going to "cpuinfo" in "/proc." Though you don't get anywhere near as much info, sometimes "cpuinfo" contains enough information. To get that info execute the command:
cat /proc/cpuinfo
Example output below:
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
stepping : 1
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
bogomips : 2010.87
clflush size : 64
power management: ts fid vid ttp tm stc 100mhzsteps
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
stepping : 1
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
bogomips : 2010.87
clflush size : 64
power management: ts fid vid ttp tm stc 100mhzsteps
Hopefully these simple Linux utilities will come in handy for you as you get handed new servers to maintain...
