测试80端口
nc -z -w 1 www.google.com 80
nmap -sT www.google.com -p 80
测试UDP 53端口
nc -u -z -w 1 8.8.8.8 53
nmap -sU 8.8.8.8 -p 53
测试80端口
nc -z -w 1 www.google.com 80
nmap -sT www.google.com -p 80
测试UDP 53端口
nc -u -z -w 1 8.8.8.8 53
nmap -sU 8.8.8.8 -p 53
内容来源于网络
查看RAM使用情况最简单的方法是通过/proc/meminfo
。这个动态更新的虚拟文件实际上是许多其他内存相关工具(如:free / ps / top)等的组合显示。/proc/meminfo
列出了所有你想了解的内存的使用情况。进程的内存使用信息也可以通过/proc/<pid>/statm 和 /proc/<pid>/status 来查看。
1 |
$ cat /proc/meminfo |
atop命令是一个终端环境的监控命令。它显示的是各种系统资源(CPU, memory, network, I/O, kernel)的综合,并且在高负载的情况下进行了彩色标注。
1 |
$ sudo atop |
free命令是一个快速查看内存使用情况的方法,它是对 /proc/meminfo 收集到的信息的一个概述。
1 |
$ free -h |
GNOME System Monitor 是一个显示最近一段时间内的CPU、内存、交换区及网络的使用情况的视图工具。它还提供了一种查看CPU及内存使用情况的方法。
1 |
$ gnome-system-monitor |
htop命令显示了每个进程的内存实时使用率。它提供了所有进程的常驻内存大小、程序总内存大小、共享库大小等的报告。列表可以水平及垂直滚动。
1 |
$ htop |
功能同 4 中介绍的GENOME版本。
1 |
$ ksysguard |
memstat是一个有效识别executable(s), process(es) and shared libraries使用虚拟内存情况的命令。给定一个进程ID,memstat可以列出这个进程相关的可执行文件、数据和共享库。
1 |
$ memstat -p <PID> |
nmon是一个基于ncurses的系统基准测试工具,它可以监控CPU、内存、I/O、文件系统及网络资源等的互动模式。对于内存的使用,它可以实时的显示 总/剩余内存、交换空间等信息。
1 |
$ nmon |
ps命令可以实时的显示各个进程的内存使用情况。Reported memory usage information includes
%MEM (percent of physical memory used), VSZ (total amount of virtual
memory used), and RSS (total amount of physical memory used)。你可以使用
“–sort”选项对进程进行排序,例如按RSS进行排序:
1 |
$ ps aux --sort -rss |
smem命令允许你统计基于/proc信息的不同进程和用户的内存使用情况。内存使用情况的分析可以导出图表(如条形图和饼图)。
1 |
$ sudo smem --pie name -c "pss" |
top命令提供了实时的运行中的程序的资源使用统计。你可以根据内存的使用和大小来进行排序。
1 |
$ top |
vmstat命令显示实时的和平均的统计,覆盖CPU、内存、I/O等内容。例如内存情况,不仅显示物理内存,也统计虚拟内存。
1 |
$ vmstat -s |
测试随机写IOPS:
fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k
-size=10G -numjobs=1 -runtime=1000 -group_reporting
-name=/path/testfile
测试随机读IOPS:
fio -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k
-size=10G -numjobs=1 -runtime=1000 -group_reporting
-name=/path/testfile
测试写吞吐量:
fio -direct=1 -iodepth=64 -rw=randwrite -ioengine=libaio -bs=64k
-size=10G -numjobs=1 -runtime=1000 -group_reporting
-name=/path/testfile
测试读吞吐量:
fio -direct=1 -iodepth=64 -rw=randread -ioengine=libaio -bs=64k
-size=10G -numjobs=1 -runtime=1000 -group_reporting
-name=/path/testfile
案例:
写:time dd if=/dev/zero of=/mnt/mfs/test2/test500M bs=1024k count=500
读:time dd if=/mnt/mfs/test2/test500M of=/dev/null
1copy写 | 2copy写 | 1copy读 | 2copy读 | |
1M | 0m0.042s | 0m0.042s | 0m0.017s | 0m0.017s |
5M | 0m0.073s | 0m0.079s | 0m0.070s | 0m0.071s |
20M | 0m0.250s | 0m0.288s | 0m0.291s | 0m0.376s |
50M | 0m0.514s | 0m0.589s | 0m0.896s | 0m0.886s |
100M | 0m0.977s | 0m7.497s | 0m1.677s | 0m1.787s |
200M | 0m7.910s | 0m22.270s | 0m2.683s | 0m3.129s |
500M | 0m22.465s | 0m51.735s | 0m6.559s | 0m6.990s |
1G | 0m52.346s | 1m48.056s | 0m17.319s | 0m17.154s |
2G | 1m46.224s | 3m46.283s | 0m41.608s | 0m34.435s |
10G | 9m29.037s | 19m26.237s | 3m55.222s | 3m24.914s |
...
MSDN建议按照下面的模式实现IDisposable接口:
public class Foo: IDisposable { public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) |
CSDN上一位高手的总结
1、Finalize方法(C#中是析构函数,以下称析构函数)是用于释放非托管资源的,而托管资源会由GC自动回收。所以,我们也可以这样来区分 托管和非托管资源。所有会由GC自动回收的资源,就是托管的资源,而不能由GC自动回收的资源,就是非托管资源。在我们的类中直接使用非托管资源的情况很 少,所以基本上不用我们写析构函数。
2、大部分的非托管资源会给系统带来很多负面影响,例如数据库连接不被释放就可能导致连接池中的可用数据库连接用尽。文件不关闭会导致其它进程无法读写这个文件等等。
实现模型:
1、由于大多数的非托管资源都要求可以手动释放,所以,我们应该专门为释放非托管资源公开一个方法。实现IDispose接口的Dispose方法是最好的模型,因为C#支持using语句快,可以在离开语句块时自动调用Dispose方法。
2、虽然可以手动释放非托管资源,我们仍然要在析构函数中释放非托管资源,这样才是安全的应用程序。否则如果因为程序员的疏忽忘记了手动释放非托管资源, 那么就会带来灾难性的后果。所以说在析构函数中释放非托管资源,是一种补救的措施,至少对于大多数类来说是如此。
3、由于析构函数的调用将导致GC对对象回收的效率降低,所以如果已经完成了析构函数该干的事情(例如释放非托管资源),就应当使用SuppressFinalize方法告诉GC不需要再执行某个对象的析构函数。
4、析构函数中只能释放非托管资源而不能对任何托管的对象/资源进行操作。因为你无法预测析构函数的运行时机,所以,当析构函数被执行的时候,也许你进行操作的托管资源已经被释放了。这样将导致严重的后果。
5、(这是一个规则)如果一个类拥有一个实现了IDispose接口类型的成员,并创建(注意是创建,而不是接收,必须是由类自己创建)它的实例对象,则 这个类也应该实现IDispose接口,并在Dispose方法中调用所有实现了IDispose接口的成员的Dispose方法。
只有这样的才能保证所有实现了IDispose接口的类的对象的Dispose方法能够被调用到,确保可以手动释放任何需要释放的资源。
进阶:
在.NET的对象中实际上有两个用于释放资源的函数:Dispose和Finalize。Finalize的目的是用于释放非托管的资源,而Dispose是用于释放所有资源,包括托管的和非托管的。
在这个模式中,void Dispose(bool disposing)函数通过一个disposing参数来区别当前是否是被Dispose()调用。如果是被Dispose()调用,那么需要同时释放 托管和非托管的资源。如果是被~Foo()(也就是C#的Finalize())调用了,那么只需要释放非托管的资源即可。
这是因为,Dispose()函数是被其它代码显式调用并要求释放资源的,而Finalize是被GC调用的。在GC调用的时候Foo所引用的其它 托管对象可能还不需要被销毁,并且即使要销毁,也会由GC来调用。因此在Finalize中只需要释放非托管资源即可。另外一方面,由于在 Dispose()中已经释放了托管和非托管的资源,因此在对象被GC回收时再次调用Finalize是没有必要的,所以在Dispose()中调用 GC.SuppressFinalize(this)避免重复调用Finalize。
然而,即使重复调用Finalize和Dispose也是不存在问题的,因为有变量m_disposed的存在,资源只会被释放一次,多余的调用会被忽略过去。
因此,上面的模式保证了:
1、 Finalize只释放非托管资源;
2、 Dispose释放托管和非托管资源;
3、 重复调用Finalize和Dispose是没有问题的;
4、 Finalize和Dispose共享相同的资源释放策略,因此他们之间也是没有冲突的。
在C#中,这个模式需要显式地实现,其中C#的~Foo()函数代表了Finalize()。而在C++/CLI中,这个模式是自动实现的,C++的类析构函数则是不一样的。
按照C++语义,析构函数在超出作用域,或者delete的时候被调用。在Managed C++(即.NET 1.1中的托管C++)中,析构函数相当于CLR中的Finalize()方法,在垃圾收集的时候由GC调用,因此,调用的时机是不明确的。在.NET 2.0的C++/CLI中,析构函数的语义被修改为等价与Dispose()方法,这就隐含了两件事情:
1、 所有的C++/CLI中的CLR类都实现了接口IDisposable,因此在C#中可以用using关键字来访问这个类的实例。
2、 析构函数不再等价于Finalize()了。
对于第一点,这是一件好事,我认为在语义上Dispose()更加接近于C++析构函数。对于第二点,Microsoft进行了一次扩展,做法是引入了“!”函数,如下所示:
public ref class Foo
{
public:
Foo();
~Foo(); // destructor
!Foo(); // finalizer
};
“!”函数(我实在不知道应该怎么称呼它)取代原来Managed C++中的Finalize()被GC调用。MSDN建议,为了减少代码的重复,可以写这样的代码:
~Foo()
{
//释放托管的资源
this->!Foo();
}
!Foo()
{
//释放非托管的资源
}
对于上面这个类,实际上C++/CLI生成对应的C#代码是这样的:
public class Foo { private void !Foo() { private void ~Foo() |
由于~Foo()和!Foo()不会被重复调用(至少MS这样认为),因此在这段代码中没有和前面m_disposed相同的变量,但是基本的结构是一样的。
并且,可以看到实际上并不是~Foo()和!Foo()就是Dispose和Finalize,而是C++/CLI编译器生成了两个Dispose 和Finalize函数,并在合适的时候调用它们。C++/CLI其实已经做了很多工作,但是唯一的一个问题就是依赖于用户在~Foo()中调 用!Foo()。
他人写的一段小程序(仅拷贝,未验证)
测试:
public class b : IDisposable { public int i; public b() { Console.WriteLine( "ctor" ); } ~b() { Console.WriteLine( "dtor" ); } public void Dispose() { Console.WriteLine( "Dispose" ); GC.SuppressFinalize( true ); } } class Program { static void Main( string [] args) { b objb = new b { i = 2 }; using (objb) { Console.WriteLine( "using" ); } Console.WriteLine( "after using" ); } } |
输出:
ctor using Dispose after using dtor Press any key to continue . . . |
using System; using System.IO; namespace NETCFDevelopersReference { /// <summary> /// Replacement for HttpUtility.UrlEncode /// </summary> public class HttpUtility { public static string UrlEncode(string instring) { StringReader strRdr = new StringReader(instring); StringWriter strWtr = new StringWriter(); int charValue = strRdr.Read(); while (charValue != -1) { if (((charValue >= 48) && (charValue <= 57)) // 0-9 ││((charValue >= 65) && (charValue <= 90)) // A-Z ││((charValue >= 97) && (charValue <= 122))) // a-z strWtr.Write((char) charValue); else if (charValue == 32) // Space strWtr.Write('+'); else strWtr.Write("%{0:x2}", charValue); charValue = strRdr.Read();} return strWtr.ToString(); } } } |
一 参考资料
1 Emoji 全编码表:(我参考的这个)
http://punchdrunker.github.com/iOSEmoji/table_html/flower.html
2 Emoji全编码表
http://code.iamcal.com/php/emoji/
http://blog.csdn.net/iunion/article/details/7241945
3 iOS5/4 Emoji 兼容性:
http://stackoverflow.com/questions/7856775/how-to-convert-the-old-emoji-encoding-to-the-latest-encoding-in-ios5
4 MySQL emoji问题
http://dropblood.com/archives/ios-mysql-emoji
5 Emoji 中文对应表
http://www.iapps.im/wp-content/uploads/2012/02/emoji-pinyin.png?r=010
6 Emoji 参考
http://www.unicode.org/emoji/
对照:
http://www.unicode.org/Public/emoji/2.0//emoji-data.txt
http://www.unicode.org/Public/emoji/2.0//emoji-sequences.txt
http://www.unicode.org/Public/emoji/2.0//emoji-zwj-sequences.txt
7 Emoji UTF-16
http://punchdrunker.github.io/iOSEmoji/table_html/emoji.json
8 windows 7 补丁
https://support.microsoft.com/zh-cn/kb/2729094
9 php
http://ju.outofmemory.cn/entry/46760
http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html
二 下载资源
emoji图片和编码表 http://download.csdn.net/detail/qdkfriend/4309051
包括emoji文件表,emoji数据编码表(Unicode编码,UTF8编码,UTF16编码,SBUnicode编码)
public static function removeEmoji($text) { $clean_text = ""; // Match Emoticons $regexEmoticons = '/[\x{1F600}-\x{1F64F}]/u'; $clean_text = preg_replace($regexEmoticons, '', $text); // Match Miscellaneous Symbols and Pictographs $regexSymbols = '/[\x{1F300}-\x{1F5FF}]/u'; $clean_text = preg_replace($regexSymbols, '', $clean_text); // Match Transport And Map Symbols $regexTransport = '/[\x{1F680}-\x{1F6FF}]/u'; $clean_text = preg_replace($regexTransport, '', $clean_text); // Match Miscellaneous Symbols $regexMisc = '/[\x{2600}-\x{26FF}]/u'; $clean_text = preg_replace($regexMisc, '', $clean_text); // Match Dingbats $regexDingbats = '/[\x{2700}-\x{27BF}]/u'; $clean_text = preg_replace($regexDingbats, '', $clean_text); return $clean_text; }
static string EmojiToHex(string content) { if (string.IsNullOrEmpty(content)) { return content; } //http://punchdrunker.github.io/iOSEmoji/table_html/emoji.json var regexString = @"\uD83C[\uDC00-\uDFFF]|\uD83D[\uDC00-\uDEFF]"; var regex = new System.Text.RegularExpressions.Regex(regexString); var contentHex = regex.Replace(content, m => { int r; string r1, r2; r = Convert.ToInt32(m.Value[0]); r1 = "0x" + r.ToString("X"); r = Convert.ToInt32(m.Value[1]); r2 = "0x" + r.ToString("X"); return r1 + r2; }); return contentHex; } static string EmojiFromHex(string hexContent) { if (string.IsNullOrEmpty(hexContent)) { return hexContent; } var regexString = @"0x[0-9A-Z]{4}|0x[0-9A-Z]{2}"; var regex = new System.Text.RegularExpressions.Regex(regexString); var content = regex.Replace(hexContent, m => { var b = m.Value.Substring(2); var b1 = Convert.ToInt32(b, 16); var b2 = Convert.ToChar(b1); return b2.ToString(); }); return content; } //test var c = ""; c = System.Web.HttpUtility.UrlDecode("%ud83d%ude00中文", Encoding.UTF8);// Console.WriteLine(c); //var c1 = c.ToCharArray(); var c1 = EmojiToHex(c); Console.WriteLine(c1); var c2 = EmojiFromHex(c1); Console.WriteLine(c2); return;