Search Results

Search found 58168 results on 2327 pages for 'mysql real escape string'.

Page 93/2327 | < Previous Page | 89 90 91 92 93 94 95 96 97 98 99 100  | Next Page >

  • Assembly GDB Print String

    - by Ken
    So in assembly I declare the following String: Sample db "This is a sample string",0 In GDB I type "p Sample" (without quotes) and it spits out 0x73696854. I want the actual String to print out. So I tried "printf "%s", Sample" (again, without quotes) and it spits out "Cannot access memory at address 0x73696854." Short version: How do I print a string in GDB?

    Read the article

  • Java String object creation

    - by Ajay
    Hi, 1) What is difference in thers two statements: String s1 = "abc"; and String s1 = new String("abc") 2) as i am not using new in first statement, how string object will be created Thanks

    Read the article

  • Make a String text Bold in Java Android

    - by meskh
    I want to make Habit Number: bold , I tried the HTML tag but it didn't work. I did some research but couldn't find any. Hope someone is able to help me. Thanks! String habitnumber = "Habit Number: " + String.valueOf(habitcounter); String Title = habit.getTitle(); String description = habit.getDescription(); //Set text for the row tv.setText(habitnumber+ "\n" + Title + " \n" + description + "\n --------------------");

    Read the article

  • c++ std::ostringstream vs std::string::append

    - by NickSoft
    In all examples that use some kind of buffering I see they use stream instead of string. How is std::ostringstream and << operator different than using string.append. Which one is faster and which one uses less resourses (memory). One difference I know is that you can output different types into output stream (like integer) rather than the limited types that string::append accepts. Here is an example: std::ostringstream os; os << "Content-Type: " << contentType << ";charset=" << charset << "\r\n"; std::string header = os.str(); vs std::string header("Content-Type: "); header.append(contentType); header.append(";charset="); header.append(charset); header.append("\r\n"); Obviously using stream is shorter, but I think append returns reference to the string so it can be written like this: std::string header("Content-Type: "); header.append(contentType) .append(";charset=") .append(charset) .append("\r\n"); And with output stream you can do: std::string content; ... os << "Content-Length: " << content.length() << "\r\n"; But what about memory usage and speed? Especially when used in a big loop. Update: To be more clear the question is: Which one should I use and why? Is there situations when one is preferred or the other? For performance and memory ... well I think benchmark is the only way since every implementation could be different. Update 2: Well I don't get clear idea what should I use from the answers which means that any of them will do the job, plus vector. Cubbi did nice benchmark with the addition of Dietmar Kühl that the biggest difference is construction of those objects. If you are looking for an answer you should check that too. I'll wait a bit more for other answers (look previous update) and if I don't get one I think I'll accept Tolga's answer because his suggestion to use vector is already done before which means vector should be less resource hungry.

    Read the article

  • mysqld crashes on any statement

    - by ??iu
    I restarted my slave to change configuration settings to skip reverse hostname lookup on connecting and to enable the slow query log. I edited /etc/my.cnf making only these changes, then restarted mysqld with /etc/init.d/mysql restart All appeared to be well but when I connect to msyqld remotely or locally though it connects okay a slight problem is that mysqld crashes whenever you try to issue any kind of statement. The client looks like: Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 3 Server version: 5.1.31-1ubuntu2-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> show tables; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 1 Current database: mydb ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... ERROR 2003 (HY000): Can't connect to MySQL server on 'xx.xx.xx.xx' (61) ERROR: Can't connect to the server ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... ERROR 2003 (HY000): Can't connect to MySQL server on 'xx.xx.xx.xx' (61) ERROR: Can't connect to the server ERROR 2006 (HY000): MySQL server has gone away Bus error The mysqld error log looks like: 101210 16:35:51 InnoDB: Error: (1500) Couldn't read the MAX(job_id) autoinc value from the index (PRIMARY). 101210 16:35:51 InnoDB: Assertion failure in thread 140245598570832 in file handler/ha_innodb.cc line 2595 InnoDB: Failing assertion: error == DB_SUCCESS InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: about forcing recovery. 101210 16:35:51 - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=3 max_threads=600 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1328077 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x18209220 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f8d791580d0 thread_stack 0x20000 /usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8b4f89] /usr/sbin/mysqld(handle_segfault+0x383) [0x5f8f03] /lib/libpthread.so.0 [0x7f902a76a080] /lib/libc.so.6(gsignal+0x35) [0x7f90291f8fb5] /lib/libc.so.6(abort+0x183) [0x7f90291fabc3] /usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int)+0x41b) [0x781f4b] /usr/sbin/mysqld(handler::ha_open(st_table*, char const*, int, int)+0x3f) [0x6db00f] /usr/sbin/mysqld(open_table_from_share(THD*, st_table_share*, char const*, unsigned int, unsigned int, unsigned int, st_table*, bool)+0x57a) [0x64760a] /usr/sbin/mysqld [0x63f281] /usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned int)+0x626) [0x641e16] /usr/sbin/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int)+0x5db) [0x6429cb] /usr/sbin/mysqld(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int)+0x1e) [0x642b0e] /usr/sbin/mysqld(mysqld_list_fields(THD*, TABLE_LIST*, char const*)+0x22) [0x70b292] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x146d) [0x60dc1d] /usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60dda8] /usr/sbin/mysqld(handle_one_connection+0x226) [0x601426] /lib/libpthread.so.0 [0x7f902a7623ba] /lib/libc.so.6(clone+0x6d) [0x7f90292abfcd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x18213c70 = thd->thread_id=3 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 101210 16:35:51 mysqld_safe Number of processes running now: 0 101210 16:35:51 mysqld_safe mysqld restarted InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 101210 16:35:54 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 101210 16:35:56 InnoDB: Started; log sequence number 456 143528628 101210 16:35:56 [Warning] 'user' entry 'root@PSDB102' ignored in --skip-name-resolve mode. 101210 16:35:56 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=mysqld-relay-bin' to avoid this problem. 101210 16:35:56 [Note] Event Scheduler: Loaded 0 events 101210 16:35:56 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.1.31-1ubuntu2-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 101210 16:36:11 InnoDB: Error: (1500) Couldn't read the MAX(job_id) autoinc value from the index (PRIMARY). 101210 16:36:11 InnoDB: Assertion failure in thread 139955151501648 in file handler/ha_innodb.cc line 2595 InnoDB: Failing assertion: error == DB_SUCCESS InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: about forcing recovery. 101210 16:36:11 - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=1 max_threads=600 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1328077 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x18588720 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f49d916f0d0 thread_stack 0x20000 /usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8b4f89] /usr/sbin/mysqld(handle_segfault+0x383) [0x5f8f03] /lib/libpthread.so.0 [0x7f4c8a73f080] /lib/libc.so.6(gsignal+0x35) [0x7f4c891cdfb5] /lib/libc.so.6(abort+0x183) [0x7f4c891cfbc3] /usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int)+0x41b) [0x781f4b] /usr/sbin/mysqld(handler::ha_open(st_table*, char const*, int, int)+0x3f) [0x6db00f] /usr/sbin/mysqld(open_table_from_share(THD*, st_table_share*, char const*, unsigned int, unsigned int, unsigned int, st_table*, bool)+0x57a) [0x64760a] /usr/sbin/mysqld [0x63f281] /usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned int)+0x626) [0x641e16] /usr/sbin/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int)+0x5db) [0x6429cb] /usr/sbin/mysqld(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int)+0x1e) [0x642b0e] /usr/sbin/mysqld(mysqld_list_fields(THD*, TABLE_LIST*, char const*)+0x22) [0x70b292] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x146d) [0x60dc1d] /usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60dda8] /usr/sbin/mysqld(handle_one_connection+0x226) [0x601426] /lib/libpthread.so.0 [0x7f4c8a7373ba] /lib/libc.so.6(clone+0x6d) [0x7f4c89280fcd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x18599950 = thd->thread_id=1 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 101210 16:36:11 mysqld_safe Number of processes running now: 0 101210 16:36:11 mysqld_safe mysqld restarted The config is [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] innodb_file_per_table innodb_buffer_pool_size=10G innodb_log_buffer_size=4M innodb_flush_log_at_trx_commit=2 innodb_thread_concurrency=8 skip-slave-start server-id=3 # # * IMPORTANT # If you make changes to these settings and your system uses apparmor, you may # also need to also adjust /etc/apparmor.d/usr.sbin.mysqld. # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /DB2/mysql tmpdir = /tmp skip-external-locking # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1 # # * Fine Tuning # key_buffer = 16M max_allowed_packet = 16M thread_stack = 128K thread_cache_size = 8 # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched myisam-recover = BACKUP max_connections = 600 #table_cache = 64 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_limit = 1M query_cache_size = 32M # skip-federated slow-query-log skip-name-resolve Update: I followed the instructions as per http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html and set innodb_force_recovery = 4 and the logs are showing a different error but the behavior is still the same: 101210 19:14:15 mysqld_safe mysqld restarted 101210 19:14:19 InnoDB: Started; log sequence number 456 143528628 InnoDB: !!! innodb_force_recovery is set to 4 !!! 101210 19:14:19 [Warning] 'user' entry 'root@PSDB102' ignored in --skip-name-resolve mode. 101210 19:14:19 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=mysqld-relay-bin' to avoid this problem. 101210 19:14:19 [Note] Event Scheduler: Loaded 0 events 101210 19:14:19 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.1.31-1ubuntu2-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 101210 19:14:32 InnoDB: error: space object of table mydb/__twitter_friend, InnoDB: space id 1602 did not exist in memory. Retrying an open. 101210 19:14:32 InnoDB: error: space object of table mydb/access_request, InnoDB: space id 1318 did not exist in memory. Retrying an open. 101210 19:14:32 InnoDB: error: space object of table mydb/activity, InnoDB: space id 1595 did not exist in memory. Retrying an open. 101210 19:14:32 - mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=1 max_threads=600 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1328077 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x1753c070 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f7a0b5800d0 thread_stack 0x20000 /usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8b4f89] /usr/sbin/mysqld(handle_segfault+0x383) [0x5f8f03] /lib/libpthread.so.0 [0x7f7cbc350080] /usr/sbin/mysqld(ha_innobase::innobase_get_index(unsigned int)+0x46) [0x77c516] /usr/sbin/mysqld(ha_innobase::innobase_initialize_autoinc()+0x40) [0x77c640] /usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int)+0x3f3) [0x781f23] /usr/sbin/mysqld(handler::ha_open(st_table*, char const*, int, int)+0x3f) [0x6db00f] /usr/sbin/mysqld(open_table_from_share(THD*, st_table_share*, char const*, unsigned int, unsigned int, unsigned int, st_table*, bool)+0x57a) [0x64760a] /usr/sbin/mysqld [0x63f281] /usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned int)+0x626) [0x641e16] /usr/sbin/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int)+0x5db) [0x6429cb] /usr/sbin/mysqld(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int)+0x1e) [0x642b0e] /usr/sbin/mysqld(mysqld_list_fields(THD*, TABLE_LIST*, char const*)+0x22) [0x70b292] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x146d) [0x60dc1d] /usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60dda8] /usr/sbin/mysqld(handle_one_connection+0x226) [0x601426] /lib/libpthread.so.0 [0x7f7cbc3483ba] /lib/libc.so.6(clone+0x6d) [0x7f7cbae91fcd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x1754d690 = thd->thread_id=1 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.

    Read the article

  • mysql broke; how to save some of the table?

    - by user1048138
    For some reason, my mysql cant connect any more. Im running 3 wordpress websites and I need to save the tables. Thats what I really really really really care about... here is the problem: root@dev:/var/log/mysql# mysql ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Same error is display when logging in with phpmyadmin.. All of the websites display this error Error establishing a database connection

    Read the article

  • MySQL: Pacemaker cannot start the failed master as a new slave?

    - by quanta
    I'm going to setup failover for MySQL replication (1 master and 1 slave) follow this guide: https://github.com/jayjanssen/Percona-Pacemaker-Resource-Agents/blob/master/doc/PRM-setup-guide.rst Here're the output of crm configure show: node serving-6192 \ attributes p_mysql_mysql_master_IP="192.168.6.192" node svr184R-638.localdomain \ attributes p_mysql_mysql_master_IP="192.168.6.38" primitive p_mysql ocf:percona:mysql \ params config="/etc/my.cnf" pid="/var/run/mysqld/mysqld.pid" socket="/var/lib/mysql/mysql.sock" replication_user="repl" replication_passwd="x" test_user="test_user" test_passwd="x" \ op monitor interval="5s" role="Master" OCF_CHECK_LEVEL="1" \ op monitor interval="2s" role="Slave" timeout="30s" OCF_CHECK_LEVEL="1" \ op start interval="0" timeout="120s" \ op stop interval="0" timeout="120s" primitive writer_vip ocf:heartbeat:IPaddr2 \ params ip="192.168.6.8" cidr_netmask="32" \ op monitor interval="10s" \ meta is-managed="true" ms ms_MySQL p_mysql \ meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" globally-unique="false" target-role="Master" is-managed="true" colocation writer_vip_on_master inf: writer_vip ms_MySQL:Master order ms_MySQL_promote_before_vip inf: ms_MySQL:promote writer_vip:start property $id="cib-bootstrap-options" \ dc-version="1.0.12-unknown" \ cluster-infrastructure="openais" \ expected-quorum-votes="2" \ no-quorum-policy="ignore" \ stonith-enabled="false" \ last-lrm-refresh="1341801689" property $id="mysql_replication" \ p_mysql_REPL_INFO="192.168.6.192|mysql-bin.000006|338" crm_mon: Last updated: Mon Jul 9 10:30:01 2012 Stack: openais Current DC: serving-6192 - partition with quorum Version: 1.0.12-unknown 2 Nodes configured, 2 expected votes 2 Resources configured. ============ Online: [ serving-6192 svr184R-638.localdomain ] Master/Slave Set: ms_MySQL Masters: [ serving-6192 ] Slaves: [ svr184R-638.localdomain ] writer_vip (ocf::heartbeat:IPaddr2): Started serving-6192 Editing /etc/my.cnf on the serving-6192 of wrong syntax to test failover and it's working fine: svr184R-638.localdomain being promoted to become the master writer_vip switch to svr184R-638.localdomain Current state: Last updated: Mon Jul 9 10:35:57 2012 Stack: openais Current DC: serving-6192 - partition with quorum Version: 1.0.12-unknown 2 Nodes configured, 2 expected votes 2 Resources configured. ============ Online: [ serving-6192 svr184R-638.localdomain ] Master/Slave Set: ms_MySQL Masters: [ svr184R-638.localdomain ] Stopped: [ p_mysql:0 ] writer_vip (ocf::heartbeat:IPaddr2): Started svr184R-638.localdomain Failed actions: p_mysql:0_monitor_5000 (node=serving-6192, call=15, rc=7, status=complete): not running p_mysql:0_demote_0 (node=serving-6192, call=22, rc=7, status=complete): not running p_mysql:0_start_0 (node=serving-6192, call=26, rc=-2, status=Timed Out): unknown exec error Remove the wrong syntax from /etc/my.cnf on serving-6192, and restart corosync, what I would like to see is serving-6192 was started as a new slave but it doesn't: Failed actions: p_mysql:0_start_0 (node=serving-6192, call=4, rc=1, status=complete): unknown error Here're snippet of the logs which I'm suspecting: Jul 09 10:46:32 serving-6192 lrmd: [7321]: info: rsc:p_mysql:0:4: start Jul 09 10:46:32 serving-6192 lrmd: [7321]: info: RA output: (p_mysql:0:start:stderr) Error performing operation: The object/attribute does not exist Jul 09 10:46:32 serving-6192 crm_attribute: [7420]: info: Invoked: /usr/sbin/crm_attribute -N serving-6192 -l reboot --name readable -v 0 The full logs: http://fpaste.org/AyOZ/ The strange thing is I can starting it manually: export OCF_ROOT=/usr/lib/ocf export OCF_RESKEY_config="/etc/my.cnf" export OCF_RESKEY_pid="/var/run/mysqld/mysqld.pid" export OCF_RESKEY_socket="/var/lib/mysql/mysql.sock" export OCF_RESKEY_replication_user="repl" export OCF_RESKEY_replication_passwd="x" export OCF_RESKEY_test_user="test_user" export OCF_RESKEY_test_passwd="x" sh -x /usr/lib/ocf/resource.d/percona/mysql start: http://fpaste.org/RVGh/ Did I make something wrong?

    Read the article

  • MySQL on Linux out of memory

    - by Sunrays
    OS: Redhat Enterprise Linux Server Release 5.3 (Tikanga) Architecture: Intel Xeon 64Bit MySQL Server 5.5.20 Enterprise Server advanced edition. Application: Liferay. My database size is 200MB. RAM is 64GB. The memory consumption increases gradually and we run out of memory. Then only rebooting releases all the memory, but then process of memory consumption starts again and reaches 63-64GB in less than a day. Parameters detail: key_buffer_size=16M innodb_buffer_pool_size=3GB inndb_buffer_pool_instances=3 max_connections=1000 innodb_flush_method=O_DIRECT innodb_change_buffering=inserts read_buffer_size=2M read_rnd_buffer_size=256K It's a serious production server issue that I am facing. What could be the reason behind this and how to resolve. This is the report of 2pm today, after Linux was rebooted yesterday @ around 10pm. Output of free -m total used free shared buffers cached Mem: 64455 22053 42402 0 1544 1164 -/+ buffers/cache: 19343 45112 Swap: 74998 0 74998 Output of vmstat 2 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 43423976 1583700 1086616 0 0 1 173 22 27 1 1 98 0 0 2 0 0 43280200 1583712 1228636 0 0 0 146 1265 491 2 2 96 1 0 0 0 0 43421940 1583724 1087160 0 0 0 138 1469 738 2 1 97 0 0 1 0 0 43422604 1583728 1086736 0 0 0 5816 1615 934 1 1 97 0 0 0 0 0 43422372 1583732 1086752 0 0 0 2784 1323 545 2 1 97 0 0 Output of top -n 3 -b top - 14:16:22 up 16:32, 5 users, load average: 0.79, 0.77, 0.93 Tasks: 345 total, 1 running, 344 sleeping, 0 stopped, 0 zombie Cpu(s): 1.0%us, 0.9%sy, 0.0%ni, 98.1%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 66002772k total, 22656292k used, 43346480k free, 1582152k buffers Swap: 76798724k total, 0k used, 76798724k free, 1163616k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6434 mysql 15 0 4095m 841m 5500 S 113.5 1.3 426:53.69 mysqld 1 root 15 0 10344 680 572 S 0.0 0.0 0:03.09 init 2 root RT -5 0 0 0 S 0.0 0.0 0:00.01 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 5 root RT -5 0 0 0 S 0.0 0.0 0:00.01 migration/1 6 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1 7 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1 8 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/2 9 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/2 10 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/2 11 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/3 12 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/3 13 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/3 14 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/4 15 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/4 16 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/4 17 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/5 18 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/5 19 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/5 20 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/6 21 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/6 22 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/6 23 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/7 24 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/7 25 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/7 26 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/8 27 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/8 28 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/8 29 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/9 30 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/9 31 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/9 32 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/10 33 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/10 34 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/10 35 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/11 36 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/11 37 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/11 38 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/12 39 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/12 40 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/12 41 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/13 42 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/13 43 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/13 44 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/14 45 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/14 46 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/14 47 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/15 48 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/15 49 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/15 50 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/16 51 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/16 52 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/16 53 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/17 54 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/17 55 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/17 56 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/18 57 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/18 58 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/18 59 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/19 60 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/19 61 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/19 62 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/20 63 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/20 64 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/20 65 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/21 66 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/21 67 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/21 68 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/22 69 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/22 70 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/22 71 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/23 72 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/23 73 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/23 74 root 10 -5 0 0 0 S 0.0 0.0 0:00.02 events/0 75 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/1 76 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/2 77 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/3 78 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/4 79 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/5 80 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/6 81 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/7 82 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/8 83 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/9 84 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/10 85 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/11 86 root 10 -5 0 0 0 S 0.0 0.0 0:00.01 events/12 87 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/13 88 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/14 89 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/15 90 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/16 91 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/17 92 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/18 93 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/19 94 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/20 95 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/21 96 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/22 97 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/23 98 root 10 -5 0 0 0 S 0.0 0.0 0:00.01 khelper 615 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread 643 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0 644 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/1 645 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/2 646 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/3 647 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/4 648 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/5 649 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/6 650 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/7 651 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/8 652 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/9 653 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/10 654 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/11 655 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/12 656 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/13 657 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/14 658 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/15 659 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/16 660 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/17 661 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/18 662 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/19 663 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/20 664 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/21 665 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/22 666 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/23 667 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid 840 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0 841 root 18 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/1 842 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/2 843 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/3 844 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/4 845 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/5 846 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/6 847 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/7 848 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/8 849 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/9 850 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/10 851 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/11 852 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/12 853 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/13 854 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/14 855 root 18 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/15 856 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/16 857 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/17 858 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/18 859 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/19 860 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/20 861 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/21 862 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/22 863 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/23 866 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khubd 868 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod 1118 root 23 0 0 0 0 S 0.0 0.0 0:00.00 pdflush 1119 root 15 0 0 0 0 S 0.0 0.0 0:00.11 pdflush 1120 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 kswapd0 1121 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 kswapd1 1122 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0 1123 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 aio/1 1124 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 aio/2 1125 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/3 1126 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/4 1127 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/5 1128 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/6 1129 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/7 1130 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/8 1131 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/9 1132 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/10 1133 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/11 1134 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/12 1135 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/13 1136 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/14 1137 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/15 1138 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/16 1139 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/17 1140 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/18 1141 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/19 1142 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/20 1143 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/21 1144 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/22 1145 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/23 1308 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kpsmoused 1566 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0 1567 root 10 -5 0 0 0 S 0.0 0.0 0:00.27 ata/1 1568 root 10 -5 0 0 0 S 0.0 0.0 0:02.39 ata/2 1569 root 10 -5 0 0 0 S 0.0 0.0 0:00.07 ata/3 1570 root 10 -5 0 0 0 S 0.0 0.0 0:00.72 ata/4 1571 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/5 1572 root 10 -5 0 0 0 S 0.0 0.0 0:00.15 ata/6 1573 root 10 -5 0 0 0 S 0.0 0.0 0:00.07 ata/7 1574 root 10 -5 0 0 0 S 0.0 0.0 0:00.06 ata/8 1575 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/9 1576 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/10 1577 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/11 1578 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/12 1579 root 10 -5 0 0 0 S 0.0 0.0 0:00.14 ata/13 1580 root 10 -5 0 0 0 S 0.0 0.0 0:01.56 ata/14 1581 root 10 -5 0 0 0 S 0.0 0.0 0:00.04 ata/15 1582 root 10 -5 0 0 0 S 0.0 0.0 0:00.40 ata/16 1583 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/17 1584 root 10 -5 0 0 0 S 0.0 0.0 0:00.11 ata/18 1585 root 10 -5 0 0 0 S 0.0 0.0 0:00.03 ata/19 1586 root 10 -5 0 0 0 S 0.0 0.0 0:00.02 ata/20 1587 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/21 1588 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/22 1589 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/23 1590 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 ata_aux 1616 root 10 -5 0 0 0 S 0.0 0.0 0:17.20 scsi_eh_0 1617 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_1 1668 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_2 1669 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 qla2xxx_2_dpc 1670 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_wq_2 1671 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 fc_wq_2 1672 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 fc_dl_2 1673 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_3 1674 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 qla2xxx_3_dpc 1675 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_wq_3 1676 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 fc_wq_3 1677 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 fc_dl_3 1728 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 kstriped 1829 root 10 -5 0 0 0 S 0.0 0.0 1:09.14 kjournald 1857 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kauditd 1891 root 11 -4 13008 1188 388 S 0.0 0.0 0:00.40 udevd 4555 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/0 4556 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/1 4557 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/2 4558 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/3 4559 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/4 4560 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/5 4561 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/6 4562 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/7 4563 root 18 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/8 4564 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/9 4565 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/10 4566 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/11 4567 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/12 4568 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/13 4569 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/14 4570 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/15 4571 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/16 4572 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/17 4573 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/18 4574 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/19 4575 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/20 4576 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/21 4577 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/22 4578 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/23 4579 root 18 -5 0 0 0 S 0.0 0.0 0:00.00 kmpath_handlerd 4734 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald 4736 root 10 -5 0 0 0 S 0.0 0.0 0:04.82 kjournald 4744 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald 5238 root RT 0 87584 3648 2768 S 0.0 0.0 0:03.60 multipathd 5537 root 11 -4 27328 812 580 S 0.0 0.0 0:00.14 auditd 5539 root 7 -8 81804 768 616 S 0.0 0.0 0:00.04 audispd 5564 root 15 0 5904 632 512 S 0.0 0.0 0:00.10 syslogd 5567 root 15 0 3800 432 344 S 0.0 0.0 0:00.01 klogd 5579 root 18 0 10728 384 244 S 0.0 0.0 0:00.42 irqbalance 5592 rpc 18 0 8048 584 464 S 0.0 0.0 0:00.00 portmap 5625 root 18 0 11032 768 632 S 0.0 0.0 0:00.00 rpc.statd 5681 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/0 5682 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/1 5683 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/2 5684 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/3 5685 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/4 5686 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/5 5687 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/6 5688 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/7 5689 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/8 5690 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/9 5691 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/10 5692 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/11

    Read the article

  • Suggest me solution to track the change in test DB and replicate in Another DB

    - by Pranav
    Suggest me solution to track the change in test DB and replicate in Another DB... My Client need a script or any solution, if he has two Database, One Test DB in which he tests his data on test portal and if he find it appropriate he can use those changes to be done in main DB to display on Live site.. Fior this he needs the solution to record or track all updation/deletion/insertion, so that he can do the same in main DB if found appropriate, NOTE: we have only one server, no separate server, hence binary log replication doesnt seems to be working for my case..

    Read the article

  • problem in installing mysqlworkbench 6

    - by pavan
    Ubuntu 13.04 - 32 bit (Reading database ... 216964 files and directories currently installed.) Unpacking mysql-workbench-community (from mysql-workbench-community-6.0.6-1ubu1304-i386.deb) ... dpkg: error processing mysql-workbench-community-6.0.6-1ubu1304-i386.deb (--install): trying to overwrite '/usr/share/mysql-workbench/model_view.glade', which is also in package mysql-workbench-data 5.2.40+dfsg-2ubuntu1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for bamfdaemon ... Rebuilding /usr/share/applications/bamf-2.index... Processing triggers for desktop-file-utils ... Processing triggers for gnome-menus ... Errors were encountered while processing: mysql-workbench-community-6.0.6-1ubu1304-i386.deb Please help..

    Read the article

  • What is the structure of network managers system-connections files?

    - by Oyks Livede
    could anyone list the complete structure of the configuration files, which network manager stores for known networks in /etc/NetworkManager/system-connections for known networks? Sample (filename askUbuntu): [connection] id=askUbuntu uuid=81255b2e-bdf1-4bdb-b6f5-b94ef16550cd type=802-11-wireless [802-11-wireless] ssid=askUbuntu mode=infrastructure mac-address=00:08:CA:E6:76:D8 [ipv6] method=auto [ipv4] method=auto I would like to create some of them by my own using a script. However, before doing so I would like to know every possible option. Furthermore, this structure seems somehow to resemble the information you can get using the dbus for active connections. dbus-send --system --print-reply \ --dest=org.freedesktop.NetworkManager \ "$active_setting_path" \ # /org/freedesktop/NetworkManager/Settings/2 org.freedesktop.NetworkManager.Settings.Connection.GetSettings Will tell you: array [ dict entry( string "802-11-wireless" array [ dict entry( string "ssid" variant array of bytes "askUbuntu" ) dict entry( string "mode" variant string "infrastructure" ) dict entry( string "mac-address" variant array of bytes [ 00 08 ca e6 76 d8 ] ) dict entry( string "seen-bssids" variant array [ string "02:1A:11:F8:C5:64" string "02:1A:11:FD:1F:EA" ] ) ] ) dict entry( string "connection" array [ dict entry( string "id" variant string "askUbuntu" ) dict entry( string "uuid" variant string "81255b2e-bdf1-4bdb-b6f5-b94ef16550cd" ) dict entry( string "timestamp" variant uint64 1383146668 ) dict entry( string "type" variant string "802-11-wireless" ) ] ) dict entry( string "ipv4" array [ dict entry( string "addresses" variant array [ ] ) dict entry( string "dns" variant array [ ] ) dict entry( string "method" variant string "auto" ) dict entry( string "routes" variant array [ ] ) ] ) dict entry( string "ipv6" array [ dict entry( string "addresses" variant array [ ] ) dict entry( string "dns" variant array [ ] ) dict entry( string "method" variant string "auto" ) dict entry( string "routes" variant array [ ] ) ] ) ] I can create new setting files using the dbus (AddSettings() in /org/freedesktop/NetworkManager/Settings) passing this type of input, so explaining me this structure and telling me all possible options will also help. Afaik, this is a Dictionary{String, Dictionary{String, Variant}}. Will there be any difference creating config files directly or using the dbus?

    Read the article

  • How to make Horde connect to mysql with UTF-8 character set?

    - by jkj
    How to tell horde 3.3.11 to use UTF-8 for it's mysql connection? The $conf['sql']['charset'] only tells horde what is expected from the database. Horde uses MDB2 to connect to mysql. Is there way to force MDB2 or mysql character_set_client from php.ini? So far I found two workarounds: Force mysql to ignore character set requested by client [mysqld] skip-character-set-client-handshake=1 default-character-set=utf8 Force mysql to run SET NAMES utf8 on every connection [mysqld] init-connect='SET NAMES utf8' Both have drawbacks on multi user mysql server. The first disables converting character sets alltogether and the second one forces every connection to produce UTF-8. [EDIT] Found the problem. The 'charset' parameter was unset the last minute before sending to SQL backend. This is probably due to mysql not being able to digest utf-8 but utf8. Mysql specific mapping is required to make it work. I just worked around it by translating utf-8 - utf8. Won't work with any other databases with this patch though. --- lib/Horde/Share/sql.php.orig 2011-07-04 17:09:33.349334890 +0300 +++ lib/Horde/Share/sql.php 2011-07-04 17:11:06.238636462 +0300 @@ -753,7 +753,13 @@ /* Connect to the sql server using the supplied parameters. */ require_once 'MDB2.php'; $params = $this->_params; - unset($params['charset']); + + if ($params['charset'] == 'utf-8') { + $params['charset'] = 'utf8'; + } else { + unset($params['charset']); + } + $this->_write_db = &MDB2::factory($params); if (is_a($this->_write_db, 'PEAR_Error')) { Horde::fatal($this->_write_db, __FILE__, __LINE__); @@ -792,7 +798,13 @@ /* Check if we need to set up the read DB connection seperately. */ if (!empty($this->_params['splitread'])) { $params = array_merge($params, $this->_params['read']); - unset($params['charset']); + + if ($params['charset'] == 'utf-8') { + $params['charset'] = 'utf8'; + } else { + unset($params['charset']); + } + $this->_db = &MDB2::singleton($params); if (is_a($this->_db, 'PEAR_Error')) { Horde::fatal($this->_db, __FILE__, __LINE__);

    Read the article

  • A Real-Time HPC Approach for Optimizing Multicore Architectures

    Complex math is at the heart of many of the biggest technical challenges. With multicore processors, the type of calculations that would have required a supercomputer can now be performed in real-time, embedded environments. High-performance computing - Supercomputer - Real-time computing - Operating system - Companies

    Read the article

  • Website Optimisation - The Impact of Blended Real-time Search So Far

    Despite the initial hype surrounding the introduction of blended real-time search into internet search engines, many experts have begun to question its value to website optimisation. Real time search has been widely criticised as a cause of SERP clutter, making pages appears chaotic and leaving the user struggling to decide which links may actually provide the information they are after.

    Read the article

  • What is the maximum memory a process (MySQL) can consume on a 32-bit OS?

    - by mmattax
    I have MySQL running on a 32-bit RHEL box. The server itself has 4GB total memory with 2GB allocated to MySQL. I would like to know the max amount of memory I can put in the box and how much of that I can allocate to MySQL. I have heard both 2GB and 4GB as the per-process-limit on a 32-bit OS... Ultimately I'd like to know if I can increase the memory for MySQL without upgrading to a 64-bit OS.

    Read the article

  • How can I identify unknown query string fragments that are coming to my site?

    - by Jon
    In the Google Analytics content overview for a site that I work on, the home page is getting many pageviews with some unfamiliar query string fragments, example: /?jkId=1234567890abcdef1234567890abcdef&jt=1&jadid=1234567890&js=1&jk=key words&jsid=12345&jmt=1 (potentially identifiable IDs have been changed) It clearly looks like some kind of ad tracking info, but noone who works on the site knows where it comes from, and I haven't been able to find any useful information from searching. Is there some listing of common query string keys available anywhere? Alternatively, does anyone happen to know where these keys (jkId, jt, jadid, js, jk, jsid and jmt) might come from?

    Read the article

  • After installing mysqli phpmyadmin stop loading

    - by phreakbox
    On Linux host 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux phpmyadmin won't load after installing mysqlnd. I'm using php5, mysql AND mysqlnd. Maybe mysql and mysqlnd conflicts for phpmyadmin. Problem: If I remove mysqlnd (mysqli support), PHP5 not working with mysqli, PHP5 only works with mysql. (Results for tests: function_exists('mysqli_fetch_all') return FALSE. That's ok. If I installed mysqlnd, php5-mysqlnd, PHP works with mysql + mysqli sumulately. Problems affected after mysqlnd install: After installing mysqli (mysqlnd) support, phpmyadmin won't load. Works PHP5 mysql + mysqlnd. When installing once again phpmyadmin than mysqlnd won't load. PHP PDO and mysql only works.

    Read the article

  • mysqld crashes on any statement

    - by ??iu
    I restarted my slave to change configuration settings to skip reverse hostname lookup on connecting and to enable the slow query log. I edited /etc/my.cnf making only these changes, then restarted mysqld with /etc/init.d/mysql restart All appeared to be well but when I connect to msyqld remotely or locally though it connects okay a slight problem is that mysqld crashes whenever you try to issue any kind of statement. The client looks like: Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 3 Server version: 5.1.31-1ubuntu2-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> show tables; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 1 Current database: mydb ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... ERROR 2003 (HY000): Can't connect to MySQL server on 'xx.xx.xx.xx' (61) ERROR: Can't connect to the server ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... ERROR 2003 (HY000): Can't connect to MySQL server on 'xx.xx.xx.xx' (61) ERROR: Can't connect to the server ERROR 2006 (HY000): MySQL server has gone away Bus error The mysqld error log looks like: 101210 16:35:51 InnoDB: Error: (1500) Couldn't read the MAX(job_id) autoinc value from the index (PRIMARY). 101210 16:35:51 InnoDB: Assertion failure in thread 140245598570832 in file handler/ha_innodb.cc line 2595 InnoDB: Failing assertion: error == DB_SUCCESS InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: about forcing recovery. 101210 16:35:51 - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=3 max_threads=600 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1328077 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x18209220 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f8d791580d0 thread_stack 0x20000 /usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8b4f89] /usr/sbin/mysqld(handle_segfault+0x383) [0x5f8f03] /lib/libpthread.so.0 [0x7f902a76a080] /lib/libc.so.6(gsignal+0x35) [0x7f90291f8fb5] /lib/libc.so.6(abort+0x183) [0x7f90291fabc3] /usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int)+0x41b) [0x781f4b] /usr/sbin/mysqld(handler::ha_open(st_table*, char const*, int, int)+0x3f) [0x6db00f] /usr/sbin/mysqld(open_table_from_share(THD*, st_table_share*, char const*, unsigned int, unsigned int, unsigned int, st_table*, bool)+0x57a) [0x64760a] /usr/sbin/mysqld [0x63f281] /usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned int)+0x626) [0x641e16] /usr/sbin/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int)+0x5db) [0x6429cb] /usr/sbin/mysqld(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int)+0x1e) [0x642b0e] /usr/sbin/mysqld(mysqld_list_fields(THD*, TABLE_LIST*, char const*)+0x22) [0x70b292] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x146d) [0x60dc1d] /usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60dda8] /usr/sbin/mysqld(handle_one_connection+0x226) [0x601426] /lib/libpthread.so.0 [0x7f902a7623ba] /lib/libc.so.6(clone+0x6d) [0x7f90292abfcd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x18213c70 = thd->thread_id=3 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 101210 16:35:51 mysqld_safe Number of processes running now: 0 101210 16:35:51 mysqld_safe mysqld restarted InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 101210 16:35:54 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 101210 16:35:56 InnoDB: Started; log sequence number 456 143528628 101210 16:35:56 [Warning] 'user' entry 'root@PSDB102' ignored in --skip-name-resolve mode. 101210 16:35:56 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=mysqld-relay-bin' to avoid this problem. 101210 16:35:56 [Note] Event Scheduler: Loaded 0 events 101210 16:35:56 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.1.31-1ubuntu2-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 101210 16:36:11 InnoDB: Error: (1500) Couldn't read the MAX(job_id) autoinc value from the index (PRIMARY). 101210 16:36:11 InnoDB: Assertion failure in thread 139955151501648 in file handler/ha_innodb.cc line 2595 InnoDB: Failing assertion: error == DB_SUCCESS InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: about forcing recovery. 101210 16:36:11 - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=1 max_threads=600 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1328077 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x18588720 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f49d916f0d0 thread_stack 0x20000 /usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8b4f89] /usr/sbin/mysqld(handle_segfault+0x383) [0x5f8f03] /lib/libpthread.so.0 [0x7f4c8a73f080] /lib/libc.so.6(gsignal+0x35) [0x7f4c891cdfb5] /lib/libc.so.6(abort+0x183) [0x7f4c891cfbc3] /usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int)+0x41b) [0x781f4b] /usr/sbin/mysqld(handler::ha_open(st_table*, char const*, int, int)+0x3f) [0x6db00f] /usr/sbin/mysqld(open_table_from_share(THD*, st_table_share*, char const*, unsigned int, unsigned int, unsigned int, st_table*, bool)+0x57a) [0x64760a] /usr/sbin/mysqld [0x63f281] /usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned int)+0x626) [0x641e16] /usr/sbin/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int)+0x5db) [0x6429cb] /usr/sbin/mysqld(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int)+0x1e) [0x642b0e] /usr/sbin/mysqld(mysqld_list_fields(THD*, TABLE_LIST*, char const*)+0x22) [0x70b292] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x146d) [0x60dc1d] /usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60dda8] /usr/sbin/mysqld(handle_one_connection+0x226) [0x601426] /lib/libpthread.so.0 [0x7f4c8a7373ba] /lib/libc.so.6(clone+0x6d) [0x7f4c89280fcd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x18599950 = thd->thread_id=1 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 101210 16:36:11 mysqld_safe Number of processes running now: 0 101210 16:36:11 mysqld_safe mysqld restarted The config is [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] innodb_file_per_table innodb_buffer_pool_size=10G innodb_log_buffer_size=4M innodb_flush_log_at_trx_commit=2 innodb_thread_concurrency=8 skip-slave-start server-id=3 # # * IMPORTANT # If you make changes to these settings and your system uses apparmor, you may # also need to also adjust /etc/apparmor.d/usr.sbin.mysqld. # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /DB2/mysql tmpdir = /tmp skip-external-locking # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1 # # * Fine Tuning # key_buffer = 16M max_allowed_packet = 16M thread_stack = 128K thread_cache_size = 8 # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched myisam-recover = BACKUP max_connections = 600 #table_cache = 64 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_limit = 1M query_cache_size = 32M # skip-federated slow-query-log skip-name-resolve Update: I followed the instructions as per http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html and set innodb_force_recovery = 4 and the logs are showing a different error but the behavior is still the same: 101210 19:14:15 mysqld_safe mysqld restarted 101210 19:14:19 InnoDB: Started; log sequence number 456 143528628 InnoDB: !!! innodb_force_recovery is set to 4 !!! 101210 19:14:19 [Warning] 'user' entry 'root@PSDB102' ignored in --skip-name-resolve mode. 101210 19:14:19 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=mysqld-relay-bin' to avoid this problem. 101210 19:14:19 [Note] Event Scheduler: Loaded 0 events 101210 19:14:19 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.1.31-1ubuntu2-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 101210 19:14:32 InnoDB: error: space object of table mydb/__twitter_friend, InnoDB: space id 1602 did not exist in memory. Retrying an open. 101210 19:14:32 InnoDB: error: space object of table mydb/access_request, InnoDB: space id 1318 did not exist in memory. Retrying an open. 101210 19:14:32 InnoDB: error: space object of table mydb/activity, InnoDB: space id 1595 did not exist in memory. Retrying an open. 101210 19:14:32 - mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=1 max_threads=600 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1328077 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x1753c070 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f7a0b5800d0 thread_stack 0x20000 /usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8b4f89] /usr/sbin/mysqld(handle_segfault+0x383) [0x5f8f03] /lib/libpthread.so.0 [0x7f7cbc350080] /usr/sbin/mysqld(ha_innobase::innobase_get_index(unsigned int)+0x46) [0x77c516] /usr/sbin/mysqld(ha_innobase::innobase_initialize_autoinc()+0x40) [0x77c640] /usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int)+0x3f3) [0x781f23] /usr/sbin/mysqld(handler::ha_open(st_table*, char const*, int, int)+0x3f) [0x6db00f] /usr/sbin/mysqld(open_table_from_share(THD*, st_table_share*, char const*, unsigned int, unsigned int, unsigned int, st_table*, bool)+0x57a) [0x64760a] /usr/sbin/mysqld [0x63f281] /usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned int)+0x626) [0x641e16] /usr/sbin/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int)+0x5db) [0x6429cb] /usr/sbin/mysqld(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int)+0x1e) [0x642b0e] /usr/sbin/mysqld(mysqld_list_fields(THD*, TABLE_LIST*, char const*)+0x22) [0x70b292] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x146d) [0x60dc1d] /usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60dda8] /usr/sbin/mysqld(handle_one_connection+0x226) [0x601426] /lib/libpthread.so.0 [0x7f7cbc3483ba] /lib/libc.so.6(clone+0x6d) [0x7f7cbae91fcd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x1754d690 = thd->thread_id=1 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.

    Read the article

  • Online ALTER TABLE in MySQL 5.6

    - by Marko Mäkelä
    This is the low-level view of data dictionary language (DDL) operations in the InnoDB storage engine in MySQL 5.6. John Russell gave a more high-level view in his blog post April 2012 Labs Release – Online DDL Improvements. MySQL before the InnoDB Plugin Traditionally, the MySQL storage engine interface has taken a minimalistic approach to data definition language. The only natively supported operations were CREATE TABLE, DROP TABLE and RENAME TABLE. Consider the following example: CREATE TABLE t(a INT); INSERT INTO t VALUES (1),(2),(3); CREATE INDEX a ON t(a); DROP TABLE t; The CREATE INDEX statement would be executed roughly as follows: CREATE TABLE temp(a INT, INDEX(a)); INSERT INTO temp SELECT * FROM t; RENAME TABLE t TO temp2; RENAME TABLE temp TO t; DROP TABLE temp2; You could imagine that the database could crash when copying all rows from the original table to the new one. For example, it could run out of file space. Then, on restart, InnoDB would roll back the huge INSERT transaction. To fix things a little, a hack was added to ha_innobase::write_row for committing the transaction every 10,000 rows. Still, it was frustrating that even a simple DROP INDEX would make the table unavailable for modifications for a long time. Fast Index Creation in the InnoDB Plugin of MySQL 5.1 MySQL 5.1 introduced a new interface for CREATE INDEX and DROP INDEX. The old table-copying approach can still be forced by SET old_alter_table=0. This interface is used in MySQL 5.5 and in the InnoDB Plugin for MySQL 5.1. Apart from the ability to do a quick DROP INDEX, the main advantage is that InnoDB will execute a merge-sort algorithm before inserting the index records into each index that is being created. This should speed up the insert into the secondary index B-trees and potentially result in a better B-tree fill factor. The 5.1 ALTER TABLE interface was not perfect. For example, DROP FOREIGN KEY still invoked the table copy. Renaming columns could conflict with InnoDB foreign key constraints. Combining ADD KEY and DROP KEY in ALTER TABLE was problematic and not atomic inside the storage engine. The ALTER TABLE interface in MySQL 5.6 The ALTER TABLE storage engine interface was completely rewritten in MySQL 5.6. Instead of introducing a method call for every conceivable operation, MySQL 5.6 introduced a handful of methods, and data structures that keep track of the requested changes. In MySQL 5.6, online ALTER TABLE operation can be requested by specifying LOCK=NONE. Also LOCK=SHARED and LOCK=EXCLUSIVE are available. The old-style table copying can be requested by ALGORITHM=COPY. That one will require at least LOCK=SHARED. From the InnoDB point of view, anything that is possible with LOCK=EXCLUSIVE is also possible with LOCK=SHARED. Most ALGORITHM=INPLACE operations inside InnoDB can be executed online (LOCK=NONE). InnoDB will always require an exclusive table lock in two phases of the operation. The execution phases are tied to a number of methods: handler::check_if_supported_inplace_alter Checks if the storage engine can perform all requested operations, and if so, what kind of locking is needed. handler::prepare_inplace_alter_table InnoDB uses this method to set up the data dictionary cache for upcoming CREATE INDEX operation. We need stubs for the new indexes, so that we can keep track of changes to the table during online index creation. Also, crash recovery would drop any indexes that were incomplete at the time of the crash. handler::inplace_alter_table In InnoDB, this method is used for creating secondary indexes or for rebuilding the table. This is the ‘main’ phase that can be executed online (with concurrent writes to the table). handler::commit_inplace_alter_table This is where the operation is committed or rolled back. Here, InnoDB would drop any indexes, rename any columns, drop or add foreign keys, and finalize a table rebuild or index creation. It would also discard any logs that were set up for online index creation or table rebuild. The prepare and commit phases require an exclusive lock, blocking all access to the table. If MySQL times out while upgrading the table meta-data lock for the commit phase, it will roll back the ALTER TABLE operation. In MySQL 5.6, data definition language operations are still not fully atomic, because the data dictionary is split. Part of it is inside InnoDB data dictionary tables. Part of the information is only available in the *.frm file, which is not covered by any crash recovery log. But, there is a single commit phase inside the storage engine. Online Secondary Index Creation It may occur that an index needs to be created on a new column to speed up queries. But, it may be unacceptable to block modifications on the table while creating the index. It turns out that it is conceptually not so hard to support online index creation. All we need is some more execution phases: Set up a stub for the index, for logging changes. Scan the table for index records. Sort the index records. Bulk load the index records. Apply the logged changes. Replace the stub with the actual index. Threads that modify the table will log the operations to the logs of each index that is being created. Errors, such as log overflow or uniqueness violations, will only be flagged by the ALTER TABLE thread. The log is conceptually similar to the InnoDB change buffer. The bulk load of index records will bypass record locking. We still generate redo log for writing the index pages. It would suffice to log page allocations only, and to flush the index pages from the buffer pool to the file system upon completion. Native ALTER TABLE Starting with MySQL 5.6, InnoDB supports most ALTER TABLE operations natively. The notable exceptions are changes to the column type, ADD FOREIGN KEY except when foreign_key_checks=0, and changes to tables that contain FULLTEXT indexes. The keyword ALGORITHM=INPLACE is somewhat misleading, because certain operations cannot be performed in-place. For example, changing the ROW_FORMAT of a table requires a rebuild. Online operation (LOCK=NONE) is not allowed in the following cases: when adding an AUTO_INCREMENT column, when the table contains FULLTEXT indexes or a hidden FTS_DOC_ID column, or when there are FOREIGN KEY constraints referring to the table, with ON…CASCADE or ON…SET NULL option. The FOREIGN KEY limitations are needed, because MySQL does not acquire meta-data locks on the child or parent tables when executing SQL statements. Theoretically, InnoDB could support operations like ADD COLUMN and DROP COLUMN in-place, by lazily converting the table to a newer format. This would require that the data dictionary keep multiple versions of the table definition. For simplicity, we will copy the entire table, even for DROP COLUMN. The bulk copying of the table will bypass record locking and undo logging. For facilitating online operation, a temporary log will be associated with the clustered index of table. Threads that modify the table will also write the changes to the log. When altering the table, we skip all records that have been marked for deletion. In this way, we can simply discard any undo log records that were not yet purged from the original table. Off-page columns, or BLOBs, are an important consideration. We suspend the purge of delete-marked records if it would free any off-page columns from the old table. This is because the BLOBs can be needed when applying changes from the log. We have special logging for handling the ROLLBACK of an INSERT that inserted new off-page columns. This is because the columns will be freed at rollback.

    Read the article

  • Apache / MySql is not running. What is wrong?

    - by Valeriu
    I installed lampp / xampp on my Ubuntu 12.04. After installing, Apache and MySQL were running properly. Now, they're not. Here's what I get when I try to run apache: Command: /etc/init.d/apache2 start Result: * Starting web server apache2 /usr/sbin/apache2ctl: 87: ulimit: error setting limit (Operation not permitted) (13)Permission denied: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs Action 'start' failed. The Apache error log may have more information.

    Read the article

  • Building Real-World Microsoft BI Dashboards Today

    There is a lot of Microsoft buzz about Power BI and Excel these days, but customers need real-world, professional business intelligence solutions that meet their complex real-world requirements today. In this article, Jen Underwood shares what technologies were used to develop a dashboard solution for a Fortune Global 500 company using Microsoft Business Intelligence technologies, and why. Some of the decisions may surprise you and the lessons learned are sure to be of value.

    Read the article

  • Real Time Search and Applications

    Several companies want to improve their real time search practice. The most popular search engine Google also has plans to improvise on this area and has launched a real time search. But what exactly does this buzzword mean?

    Read the article

  • Designing Tips For Real Estate Websites

    Once you have decided to design a website for pursuing your real estate interests online, there are certain things that should be considered prior taking up any designing task. First of all, it is necessary to identify the real purpose of building a website.

    Read the article

  • Setting up MySQL Cluster 7.0 in Linux

    <b>Linux Admin Zone:</b> "You might know that beginning with MySQL 5.1.24, support for the NDBCLUSTER storage engine was removed from the standard MySQL server binaries built by MySQL. Therefore, here I&#8217;m using MySQL Cluster edition instead of MySQL Community edition."

    Read the article

  • best way to import 500MB csv file into mysql database?

    - by mars
    I have a 500MB csv file that needs to be imported into my mysql database. I've made a php file where i can upload the csv file and it analyses the fields n stuff and does the actual importing. but it can only handle small fiels max 5mb. so that's a 100 files and actually pretty slow(uploading) is there another way? I have to repeat this process every month because the data in the file changes every month it's about 12 000 000 lines :D

    Read the article

< Previous Page | 89 90 91 92 93 94 95 96 97 98 99 100  | Next Page >