昨天傍晚带儿子出去玩,回家的时候路过烤肉摊,儿子想吃烤肉,于是乎我就带儿子找了个地方坐下了,要了几个烤鸡翅和一些烤肉,当然还有两瓶冰封没有王座,然后就是无止境的等......
儿子:爸爸,我回去要告诉姥姥。
爸爸:你告诉姥姥啥?
儿子:我告诉姥姥你请我吃烤肉了。(姥姥一直反对我们老带他吃这些东西)
爸爸:不会吧,你告诉姥姥我怎么办?
儿子诡异的笑着说:你,死定了!
Sunday, June 19, 2011
Wednesday, June 8, 2011
Create multipul vertica database with different port number
最近在用Vertica数据库,想同时启动多个数据库实例,但是在启动的时候发现所有数据库实例都是使用的同一个端口:5433,这样在同一时间就只能使用一个数据库实例,这对我来说用起来就有太多限制了。于是今天下午搞了半天总算发现Vertica的端口定义文件,对于不同的数据库实例定义不同的端口就可以解决上面的问题了。步骤如下:
1. Create multipul database instances through "admintools". For example: mydb1 and mydb2;
2. Shutdown all database instances through "admintools";
3. Change port number for database instances.
Backup ${VERTICA_TOP}/config/share/portinfo.dat file, and change port number for some database instances.
For example: mydb1 uses 5433, mydb2 uses 5444.
4. Restart verticad service
$ sudo /etc/init.d/verticad restart
1. Create multipul database instances through "admintools". For example: mydb1 and mydb2;
2. Shutdown all database instances through "admintools";
3. Change port number for database instances.
Backup ${VERTICA_TOP}/config/share/portinfo.dat file, and change port number for some database instances.
For example: mydb1 uses 5433, mydb2 uses 5444.
4. Restart verticad service
$ sudo /etc/init.d/verticad restart
优美与忧郁
周六晚上,儿子想和我一起洗澡,于是就开始说好听的哄我:
儿子:爸爸,我想和你一起洗澡,晚上我和你一起睡觉。
爸爸:你又哄我,每次你都这样说,可一到睡觉的时候你就跑你妈那里去了。
儿子:那当然了,因为妈妈长的太优美了,你长的太忧郁了。
爸爸:&%……¥*&(*&%……&*
儿子:爸爸,我想和你一起洗澡,晚上我和你一起睡觉。
爸爸:你又哄我,每次你都这样说,可一到睡觉的时候你就跑你妈那里去了。
儿子:那当然了,因为妈妈长的太优美了,你长的太忧郁了。
爸爸:&%……¥*&(*&%……&*
Java文件流关闭和垃圾回收问题
周末碰到一段代码,是关于Java IO流的,代码中出现在一个多线程的系统中,其中一段代码在打开一个文件操作流用完以后没有及时关闭,开始以为很快会出现打开文件太多或者导致内存溢出,但是在运行了很长时间以后仍然没有出现问题,后来自己写了个小程序测试了一下,总算似乎搞清楚为啥了。
先看以下一段代码
在linux上编译并运行这个类,然后使用linux的命令/usr/sbin/lsof -p来查看这个程序打开的文件信息
不管是在10个线程运行过程中还是运行完,使用lsof命令查看的结果都一样,都可以看到有10个文件流没有关闭。
下面我把这个代码做了一些改动,就是在线程执行完之后,将所有线程置为null,如下
再次在10个线程运行过程中和运行完毕后使用lsof查看,结果仍然类似,还是有10个文件流没有关闭。
我再次做了一些改动,在将所有线程置为null以后,增加(或者说是催促JVM)做几次gc操作,如下:
再次使用lsof查看,在运行中仍然还是可以看到那有10个文件流打开着,但是在“Finished GC!”之后,看到的结果是那10个打开的文件流都被关闭了。
最后,我干脆把那些设置thread为null的语句删除了,运行的结果也和上面执行gc操作的结果一致。
最终,JVM中对于那些打开了没有关闭的IO文件流,会在不再被使用的情况下,等到下次做Full GC的时候把他们全部回收,但是让JVM去干这些事总归还是不好的,还是那句老话,自己的事情自己做。
先看以下一段代码
import java.io.FileInputStream;
public class TTT {
public static void main(String[] args) throws Exception {
for (int i = 0; i < 10; i++) {
final String threadId = "thread_" + i;
Thread thread = new Thread(new Runnable() {
public void run() {
System.out.println(threadId + " started!");
try {
FileInputStream fis = new FileInputStream("/opt/test.log");
Thread.sleep(60 * 1000);
} catch (Exception ex) {
ex.printStackTrace();
}
System.out.println(threadId + " stopped!");
}
});
thread.start();
}
Thread.sleep(10 * 60 * 1000);
}
}
在linux上编译并运行这个类,然后使用linux的命令/usr/sbin/lsof -p
$ /usr/sbin/lsof -p `ps -ef | grep java | grep TTT | awk '{print $2}'` | grep "test.log"
java 21562 fkong 3r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 4r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 5r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 6r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 7r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 8r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 9r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 10r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 11r REG 253,0 0 35471424 /opt/test.log
java 21562 fkong 12r REG 253,0 0 35471424 /opt/test.log
不管是在10个线程运行过程中还是运行完,使用lsof命令查看的结果都一样,都可以看到有10个文件流没有关闭。
下面我把这个代码做了一些改动,就是在线程执行完之后,将所有线程置为null,如下
import java.io.FileInputStream;
import java.util.ArrayList;
import java.util.List;
public class TTT {
public static void main(String[] args) throws Exception {
Listthreads = new ArrayList ();
for (int i = 0; i < 10; i++) {
final String threadId = "thread_" + i;
Thread thread = new Thread(new Runnable() {
public void run() {
System.out.println(threadId + " started!");
try {
FileInputStream fis = new FileInputStream("/opt/test.log");
Thread.sleep(60 * 1000);
} catch (Exception ex) {
ex.printStackTrace();
}
System.out.println(threadId + " stopped!");
}
});
thread.start();
threads.add(thread);
}
Thread.sleep(2 * 60 * 1000);
for (Thread thread : threads) {
thread = null;
}
System.out.println("Clean up threads!");
Thread.sleep(10 * 60 * 1000);
}
}
再次在10个线程运行过程中和运行完毕后使用lsof查看,结果仍然类似,还是有10个文件流没有关闭。
我再次做了一些改动,在将所有线程置为null以后,增加(或者说是催促JVM)做几次gc操作,如下:
import java.io.FileInputStream;
import java.util.ArrayList;
import java.util.List;
public class TTT {
public static void main(String[] args) throws Exception {
Listthreads = new ArrayList ();
for (int i = 0; i < 10; i++) {
final String threadId = "thread_" + i;
Thread thread = new Thread(new Runnable() {
public void run() {
System.out.println(threadId + " started!");
try {
FileInputStream fis = new FileInputStream("/opt/test.log");
Thread.sleep(60 * 1000);
} catch (Exception ex) {
ex.printStackTrace();
}
System.out.println(threadId + " stopped!");
}
});
thread.start();
threads.add(thread);
}
Thread.sleep(2 * 60 * 1000);
for (Thread thread : threads) {
thread = null;
}
System.out.println("Clean up threads!");
System.gc();
System.gc();
System.gc();
System.out.println("Finished GC!");
Thread.sleep(10 * 60 * 1000);
}
}
再次使用lsof查看,在运行中仍然还是可以看到那有10个文件流打开着,但是在“Finished GC!”之后,看到的结果是那10个打开的文件流都被关闭了。
最后,我干脆把那些设置thread为null的语句删除了,运行的结果也和上面执行gc操作的结果一致。
最终,JVM中对于那些打开了没有关闭的IO文件流,会在不再被使用的情况下,等到下次做Full GC的时候把他们全部回收,但是让JVM去干这些事总归还是不好的,还是那句老话,自己的事情自己做。
不使用临时变量的变量交换算法
最近无聊写的一段小程序
#include
void swap(int *px, int *py);
int main() {
int x = 1, y = 2;
printf("x=%d, y=%d\n", x, y);
swap(&x, &y);
printf("x=%d, y=%d\n", x, y);
return 0;
}
void swap(int *px, int *py) {
*px = *px + *py;
*py = *px - *py;
*px = *px - *py;
}
Subscribe to:
Posts (Atom)